Posted on
Updated on
December 3, 2021
REDCap Adverse Event Reporting
The REDCap Adverse Event Reporting External Module is an application that facilitates the creation of Adverse Event (AE) reports aiming to create the ClinicalTrials.gov (CT) AE template. It also creates a generalized IRB AE template, as well as an FDA AE Template. The application allows for two modes of operation:
- it can connect and load data from an existing REDCap project
- it can act as an additional REDCap project that collects AE data.
In both cases it provides means for aggregating the project's adverse event data, and thus creating the mentioned AE reports. Its goal is to eliminate aggregation steps, minimize redundant steps, and successfully create the CT AE template. Continue reading to learn how to get started.
System Requirements
- REDCap v8.5 or greater
- Secure Website Protocol (i.e. HTTPS and not HTTP)
- REDCap's API up-and-running, enabled, and ready to go
- PHP 7.2
Recommended System Setup and Notice for REDCap Admin
Download the application from REDCap's External Module Repo, and enable it according to your institution's policies around External Modules.
The application requires an underlying REDCap project, referred to as host project, to function properly. The application will not work if this External Module is enabled on a project that does not contain the expected project structure and field requirements. As a simple system check the application was designed with a read-only system check that will inform the user if the underlying REDCap project (that is, the project in which this External Module was enabled) meets the expected requirements. The read-only system check is not intrusive and should pose no problem if it run on an existing project by mistake. The required (host) REDCap project is provided with this External Module, as and XML-file, and can be downloaded from within this document. Alternatively, the REDCap Administrator can opt for creating a REDCap template of this XML-file. Plus, the application provides a training submodule that aims to guide the REDCap user, step by step, how to use the entire application. It provides the appropriate XML-files to create mock REDCap Studies that contain mock adverse event data, and it explains how to connect these mock projects to the Adverse Event Reporting external module. It is important to note that a REDCap user can enable this External Module as many times as needed in their respective host projects, but every instance can only connect to one REDCap Project.
Furthermore, the application provides documentation in every phase of its functionality. It starts on this document by outlining what it is and how to get started. Then, it provides a training submodule with its own documentation, as well as a Help tab available at any time from within the application. The Help tab contains a FAQ section, plus other how-to and what-and-why explanations of different aspects of the application.
Finally, it is recommended that REDCap users new to this External Module first enable it on a test project and practice with it (using the provided host and mock projects, taking advantage of the its mock adverse event data). Once comfortable with its look, feel, and function, the REDCap user can start collecting Adverse Event data in this test project or create a new project - it's their choice.
External Module Configuration
The external module allows for configuring how many fields to be collected, and it allows adding up to 5 customizable fields. Additionally, it allows to specify IRB contact information. The purpose of this feature it to allow REDCap Admins to customize the external module with their local IRB contact information. Please take a moment to review these settings before enabling for end-users. It is recommended that you check with your local IRB and determine the expected IRB requirements for Adverse Events reporting.
End-User Instructions
1. Getting Started - Setting up a host project
The functionality of the Adverse Event Reporting application is based on an underlying REDCap project, referred to as host project, that must be installed before the application can be used. The REDCap project needed is provided with this application in form of an XML-file. Download this file by right-clicking the next link, select Save As and save it in your local machine:
1.a) Download Host Project
The file contains the required metadata for the host project. It must be installed in REDCap as a new project by uploading its XML-file when prompted by REDCap. Follow these instructions to install it successfully:
- Go to "My Projects" and create a new project by clicking the "+ New Project"
- Choose and enter the project's title, i.e. "Adverse Event Reporting - Study Trial"
- Enter the rest of the required fields
- On the section of "Start project from scratch or begin with a template?", select "Upload REDCap project XML file (CDISC ODM Format)" as shown by the following image:
- Click on "Choose File" and select the file downloaded above named "adv_event_host_project.xml". Click OK.
- Once successful, the new project's "Project Setup" page will load. Verify that the project loaded successfully clicking on "Online Designer" and ensuring the following instruments are present.
- Click on "Define Events" to verify that the project contains the expected following four arms:
- Project Mappings
- Worksheet
- IRB AE Log
- CT AE Log
- Verify that the "CT AE Log" is the only instrument set to be a Repeated Instrument, and "ClinicalTrails AE Arm Total" is the only instrument marked as repeatable.
- Finally, set the project to Production Mode.
2. Getting Started - Enabling and Starting the AE Reporting External Module in a Project
Enabling the Module
REDCap External Modules are enabled withing a project by going to:
- Applications >> External Modules >> Enable Module
Click the "Enable a Module" button, find the Adverse Event External Module and click enable to make it available within your project. Here's what you should be looking for*:
*If your project's "Enable a Module" link does not show the Adverse Event External Module is because the REDCap administrator has not installed/enabled it on the system. At this point, you have to contact the REDCap administrator and request it.
Starting the Module
Enabling the Adverse Event Reporting module in a project adds a link on the External Module section on the left-hand side REDCap menu. Click this link, as shown below, to start the application.
If done successfully, the application will load and it will show its home page. It should look as follows:
Home Page and Getting Started:
Welcome to the overview of the Adverse Event Reporting solution. It explains the purpose, approach, and details of how using this tool facilitates the accuracy of Adverse Event Reporting. First and foremost, it needs to be clarified that this solution can help the reporting of adverse events for:
- existing REDCap projects
- REDCap projects in the early stages of data collection.
Purpose:
Facilitate the reporting of adverse events by providing a structured process for ensuring adverse event reporting requirements are met.
Overview:
The main functionality of the Adverse Event Reporting solution is the identification of adverse event records and aggregation of their corresponding adverse event terms. The goal is to facilitate its reporting to governing bodies, i.e. IRB, Clinical Trails.gov, and/or FDA. The proposed solution facilitates the aggregation of the adverse event terms for two main cases: existing, and new REDCap projects. In the case that a research study is being hosted in REDCap and it's been collecting adverse event data, the adverse event reporting solution can connect to the existing project with the goal of generating the corresponding adverse events reporting templates. On the other hand, in the case of a research study that is in the early stages of collecting data, the adverse event reporting solution can be used as the host of the adverse event data itself, and thus simplifying the requirements for the research project. The solution is able to connect to or different types of REDCap Projects:
- Wide projects
- Wide projects with Events
- Projects with adverse event data in a project Arm
- Projects with adverse event data in a completely separate REDCap project
The external module connects to these types of projects through an API token, specified by the end-user. The process begins by setting-up a field mapping stage in which the fields of the source project (project that contains the Adverse Event data) are sorted through and the fields collecting adverse event data are identified. Then, in the case that the data being collected is not ideal, or does not meet the expected requirements, the data can be cleaned until it meets the expected requirements. Such step is done is the Worksheet stage. Once the data has been prepared, it can then be aggregated and the adverse event templates can be created. These templates are automatically created for the end-user.
Furthermore, the proposed solution also provides an alternative for research projects that are in the beginning of stages of data collection. In the case that such project is considering creating a separate REDCap project to store adverse event data, the proposed solution can help right out-of-the-box, without the need of mapping adverse event fields, by using its Worksheet as the separate Adverse Event collection project. The Worksheet contains the required fields to create all three adverse event templates.
Requirements:
- API token with export rights from the source project
- In-depth knowledge of the source project data dictionary to identify the adverse event fields
- Access to the source project for determining total records and/or total of number of subjects at risk
- Able to identify the number of arms in the study
FAQs:
Q: What is the goal of this application?
A: Facilitate the reporting of adverse events by providing a structured process for ensuring adverse event reporting requirements are met.
A: Facilitate the reporting of adverse events by providing a structured process for ensuring adverse event reporting requirements are met.
Q: What is the source project?
A: The source project is an existing project where the researcher's (PI) is hosting adverse event data.
A: The source project is an existing project where the researcher's (PI) is hosting adverse event data.
Q: What are the target, source, and alternate fields?
A: Target fields are a set of placeholder fields for mapping values from source or alternate fields. Source fields are fields from the source project that contain the exact values of the target fields they are being mapped to. Alternate fields are fields from the source project that contain the best, but not exact, data type available for the target field.
A: Target fields are a set of placeholder fields for mapping values from source or alternate fields. Source fields are fields from the source project that contain the exact values of the target fields they are being mapped to. Alternate fields are fields from the source project that contain the best, but not exact, data type available for the target field.
Q: Who has access to sensitive adverse event data?
A: Only project staff listed in the researcher's project hosting adverse event data.
A: Only project staff listed in the researcher's project hosting adverse event data.
Q: How is adverse event data accessed?
A: Through an API (data) Export token requested by the PI and/or project staff
A: Through an API (data) Export token requested by the PI and/or project staff
Q: Where does the adverse event data go after being exported using the API token?
A: The adverse event data from the researcher's source project is exported from a REDCap project, and it goes straight into it. It is up to the PI and/or PI's staff to make proper use the API token and make the API call from a safe and secure REDCap instance.
A: The adverse event data from the researcher's source project is exported from a REDCap project, and it goes straight into it. It is up to the PI and/or PI's staff to make proper use the API token and make the API call from a safe and secure REDCap instance.
Q: Where does the processing of the adverse event data takes place?
A: It takes place within your local instance of REDCap. The processing of adverse event data is done in REDCap's backend server under the same local infrastructure environment.
A: It takes place within your local instance of REDCap. The processing of adverse event data is done in REDCap's backend server under the same local infrastructure environment.
Q: Why is loaded data not being displayed in the Worksheet Review Panel?
A: If the field mapped into the Source field does not contain the expected values of its Target field, the Worksheet Review panel will not display the data that was mapped into it, because it's considered to be bad data that does not meet the Target field's requirements. In this case, it is recommended that the mapping used for the source field, be mapped into the respective alternate field; doing this will load the data as record details that can be used to compose the target field's data in the Worksheet.
A: If the field mapped into the Source field does not contain the expected values of its Target field, the Worksheet Review panel will not display the data that was mapped into it, because it's considered to be bad data that does not meet the Target field's requirements. In this case, it is recommended that the mapping used for the source field, be mapped into the respective alternate field; doing this will load the data as record details that can be used to compose the target field's data in the Worksheet.
Q: Where can I find the requirements for building the adverse event report for clinical-trails.gov?
A: The requirements are available online and they can be found here: https://prsinfo.clinical-trials.gov/results_definitions.html
A: The requirements are available online and they can be found here: https://prsinfo.clinical-trials.gov/results_definitions.html
Mapping and Loading data
Getting Started:
The mapping stage refers to mapping fields from the source project (the researcher's project containing the source adverse event data) to the target project (the underlying REDCap project of the Adverse Event Reporting solution.) There are 17+ fields that must be mapped in order to generate the three adverse event templates. Depending on the adverse event template you're aiming to generate, you might not be required to map all fields. All fields are mapped through drop down options. These mapping drop downs are initially blank (and contain a default value of Y). In order to see the fields of the source project it is necessary to connect to it using an API token. Use the "Settings" window to specify the token that has export rights from the source project.
How and what to request from the API Token?
Request API access, with export rights only, to your REDCap Administrator. The API token must belong to the project hosting raw adverse event data, not the project in which the Adverse Event External Module was enabled.
Field Mapping
Field mapping is straight forward - each drop down will list all the fields found in the source project data dictionary. It is the job of the end-user to select the appropriate field that maps to the target fields. In the case that the source project was built longitudinal with arm/events, the mapping options will display an additional target field asking to identify the arm in which adverse events are to be found. In practice, it might be unrealistic to find fields in an existing research project that directly map to the target fields. In this case, alternate fields have been included. The alternate fields are to be used with fields that do not have a direct mapping, from the source to the target project. The following image shows the ideal case in which the source project contains fields named identically to the target fields. It also shows how target fields can be mapped from alternate fields. For a complete list of target field definition please see this document.
Specifying the number of Study Arms:
Knowing the number of study arms is required for generating the FDA and the Clinical Trials.gov adverse event template. The requirement for these fields is to state the amount of subject at risk per arm. In turn, unless otherwise noticed by the researcher, the amount of subject at risk per arm is the number of unique subject per arm, which could essentially be all existing records per arm if a subject is enrolled only once. The amount of study arms is specified in the settings button found in the upper right side of the mapping page. Entering the number of arms in the appropriate place, as shown below, adds fields at the end of the list of mapping fields for each of the study arms. The corresponding totals are expected to be known and completed by the end-user.
Specifying Affected field mapping:
The affected field mapping is essential for creating the adverse event reports. In essence, these adverse event reports only contain a list and/or information of records affected by an adverse event, and thus it cannot contain anything else. The affected field mapping must identify a field in the source project that all records with an adverse event, but no other, contain. It is this mapping that will identify records, from the source project, as records affected with an adverse event. For instance:
if a separate REDCap project has already been built that host only adverse event data, the "date of adverse event" field of this project could be used as the mapping of the Affected field, because the date of adverse event is the most likely data point that might be available to all adverse event records.
in a REDCap project with arms and events, in which one of the arms is dedicated for collecting adverse event data, the best mapping for the affected field would be a field in the project arm recording adverse event data that all records contain.
If no mapping is specified for Affected field mapping, then no records will be loaded into the Worksheet for further processing.
in a REDCap project with arms and events, in which one of the arms is dedicated for collecting adverse event data, the best mapping for the affected field would be a field in the project arm recording adverse event data that all records contain.
If no mapping is specified for Affected field mapping, then no records will be loaded into the Worksheet for further processing.
Saving your work:
The field mappings are not saved automatically. Make sure you save your work by using the save button on the lower right hand side of the screen. The save button only saves the mappings in the current page, and it does not load the data mapped by neither the source or alternate mapping field.
Loading mapped data:
The loading of the data takes place by using the Load button found at the bottom right hand side of the screen. The Load button loads all of the data identified by mapped fields. Keep in mind that the data required is only adverse event records; in terms of the Clinical Trials.gov requirements, it requires only affected records. The Load button will only load records that have been identified by the Affected target field. For example, if a REDCap project contains a total of 238 records, of which 34 experienced an adverse event, then the Load button will only load 34 records if the appropriate mapping was given to the Affect target field. Otherwise, if no Affected field mapping is identified, the loading process will not load any records. Loading the data is a longer process than saving mappings. Please expect a longer response time when waiting for the Load to complete. The page will reload after its process has completed. At this point, you can proceed to the Worksheet stage by clicking its button found on the page's menu bar.
Worksheet and cleaning data:
Getting Started
The purpose of the Worksheet stage is to provide means for the end-user to clean the adverse event data that was not able to be directly mapped into the target fields. The worksheet states the expected values and format for each of the target fields making it easy for the end-user to identify the proper field value. Furthermore, it allows saving the progress of the work done, as well as scrolling through all loaded adverse events records. The Worksheet is composed of four essential components (please refer to the following image):
- Worksheet Review Panel: it displays the data loaded from source fields - one record at a time; allows the end-user to input, update, or modify the data mapped directly to the target field from the source field.
- Alternate Field Data Panel: it displays the data loaded from alternate fields - one record at a time; its purpose is to act as a window to the adverse event record in the source project, allowing the end-user to see the closest (record details) adverse event data for the fields in the record found in the source project. Having a window back to the source project allows the end-user to set the expected value for each field in each record of the Worksheet Review Panel.
- Record toggle: it displays the number of the record being reviewed as well as the number of records available. Its purpose is to allow the end-user to scroll through all the available records so they can be reviewed and verified before creating any adverse event report.
- Save progress button: it allows to save the changes of the record being reviewed.
Cleaning data in the Worksheet
The Worksheet stage of the solution provides a change for the end-user to review and validate the data before it is used for generating the adverse event templates. Also, it is important to set the Adverse Event Term and its corresponding Study Arm. The Alternate Field Panel can be used ensure the proper selection of the Worksheet field values, either by copying and pasting, or selecting the right answer choice from the values. Take the following use case as an example:
Use Case 1 - bad data mapped to field named Description of Events:
If the Alternate field for the mentioned field was mapped with alternate data, it is this data that can be used to determine the appropriate value needed for the target field. It can either be copied and paste it into it, or it can be typed into it.
Use Case 2 - How do I know if I've finished reviewing a record?
The alternate data field panel, under Records Details, contains a text box that can be used to leave notes in each individual record without adding it into the final adverse event report. The end-user can include record notes in the text box, which can be as simple as leaving a note stating the record has been reviewed, i.e. "This record has been completed."
Adverse Events Report Templates/Logs
IRB Adverse Event Log
The IRB adverse event log is generated at the moment its menu button is triggered from the menu bar. The adverse event (AE) log for the IRB is no more than a list of events, as it does not require any kind of aggregation. The IRB AE report can be generated at any time. It is generated by making use of the data in the Worksheet Review Panel. In the case that the adverse event records have not been completely reviewed, the IRB AE log will still be generated, but using default data stating "No Data Available" for those fields still pending to be reviewed. The fields used to compose the IRB AE log have been selected as blanket fields that cover more than it is usually requested from researcher to report, and might be enough for most IRB purposes.
Clinical-Trials.gov Adverse Event Report template
The Clinical Trials.gov adverse event report template follows a couple of steps before displaying the aggregate. It takes the cleaned adverse event records, specified in the Worksheet Review Panel, and migrates them to a repeatable event instrument in the underlying REDCap project. Then, it read the saved data and generates the report to be displayed on the screen. Furthermore, it shows the aggregation of adverse event terms per study arm, as well as the number of subjects affected as stated in the Mapping stage by the end-user. Further information about the requirements for building the adverse event report for clinical-trails.gov can be found on this website: https://prsinfo.clinical-trials.gov/results_definitions.html
FDA Adverse Event Report template
The FDA adverse event template is generated as a subset of the clinical-trail.gov template. It is generated using the same process, and it includes the identical aggregated fields.
Accessing the Adverse Event Report output file
Each adverse event report can be downloaded from the application by using the download button found on the screen. It's as simple as that - the download button will generate a file on-the-fly, based on the data being displayed on the screen, and the browser will guide you through the rest of the process.