Requirements for Custom External Modules (EM)
Include the following for inspection, review and testing:
- The Checklist for EM Development and
- The URL for the Github repository.
Each custom EM submitted to REDCap@Yale must comply with the Packaging and Documentation criteria described in the Checklist for EM Development.
Submission of modified or re-purposed Custom EMs
Often a custom EM designed for a specific study is extended or modified for use on another study. Any such modules will be treated as new submissions. Provide an explanation that identifies the previous EM and what extensions and modifications were made in the submitted EM. This will expedite the code review and testing.
Note: If the EM can be generalized, consider developing it into a global EM to be shared on the Vanderbilt site.
Code review guidelines are listed under the Coding Practices and Security sections of the Checklist for EM Development. EM developers must provide clear and compelling justifications for any deviations from these standard practices.
Static Code Review
A static code review will be performed on each submitted EM. If this review identifies any critical coding errors, or code that is problematic from the security or data integrity standpoints, the EM will be returned for revision and resubmission.
Manual Code Review
A manual code review will be performed on EMs that have passed the static code review. This analysis will focus on deviations from the criteria listed under Coding Practices in the Checklist for EM Development. If insufficient justification is provided for any deviations, additional code review may be required which will incur fees.
Dynamic Code Review
Dynamic application code review on REDCap production hosts is periodically performed by the Yale Information Security Office (ISO). Yale ISO also continuously monitors the REDCap@Yale production servers for suspicious activity. If ISO reports implicate any EM, it will be immediately disabled, and the development team notified to resolve issues.
We can provide you with access to our testing installation to safely test your work. Setting up an installation and testing may take several weeks depending on the complexity and performance of the EM. Please plan accordingly when building your development and implementation timeline.
The module’s functionality will be configured and tested according to its documentation. The module must be able to complete its functionality and not interfere with REDCap’s functionality, including the functionality of EMs that have been vetted and installed by REDCap@Yale.
Testing will also make sure that data from projects using the External Module are not erased or become inaccessible when the External Module is disabled and removed from the system. Functionality will be checked again after re-installing the module and the data should still be accessible after re-installation.
EMs will be evaluated for undue load on the REDCap host. You may be asked to provide documented scalability tests on simulated data.
EM installation, enabling and disabling will be performed by the REDCap@Yale team. EM developers should indicate the permissions required for project-level EM configuration (i.e. restricted to project designers or by user role).
The EM submission should include the anticipated end of EM support. For custom EMs this is often associated with a study phase such as the end of recruitment or follow-up.
At the approach of the designated date, the REDCap@Yale team will contact the EM developer to confirm that the EM should be disabled, or if an extension is required. If the EM is associated with a specific project, it will be disabled when the project is archived.