- Created by Liz Moyer, last modified by Nate Ariki on Oct 24, 2025
In order to provide support and administer the REDCap software to a large and growing customer base, help operations are streamlined by the designation of a project point person.
The point person is the project team member who manages their team's REDCap project for its lifespan, from creation, to the set up and design of the project, through real data collection, and to its completion.
For Standard Support projects the point person is the project team member eligible for getting support from the REDCap Team over email or at drop-in or through custom support.![]()
![]()
For Self-Service projects the point person is the project team member responsible for the project management, see below for more details. ![]()
- The person who requests the project is initially designated as the point person.
- We track the user designated as the point person by adding their name to a banner at the top of the project's home page.
- The point person is required to be an OHSU personnel (for the OCTRI partner site, Portland VA, the point person can be personnel from the partner organization who has completed our training).
Project Point Person Topics
Expectations It's not unusual for a project to transition between multiple point-persons over its lifespan. In the handoff from one point-person to the next, it's important that the study team be able to continue managing the project successfully. Here are some tips and considerations for making the transition as smooth as possible. The new point-person will need to meet the Basics training requirement to assume point-person duties. If the project includes Survey functionality, the new point person will need to complete both Basics and Survey training before taking over the project. If the new point person has completed all required trainings, you may email redcap@ohsu.edu to request that the point person be changed. Ideally, a one-on-one meeting between the departing builder and the person who will be taking over. A direct discussion can be a great way to pass knowledge of problem areas, or aspects of the project that require maintenance or just keeping an eye on. Of course, it's not always possible for this kind of discussion to take place. It becomes more important than ever to document the functionality of the project in a manual of operations (MOP). This could be in something as simple as a Word .doc saved in a location available to team members, or within the project itself using a Project Dashboard. The best time to assemble the MOP is when the build has been finalized, and the specifics about the build are fresh in mind. Any subsequent changes to the project should trigger an update to the MOP. The knowledge transfer would cover: Although, user management might seem like a set-it-and-forget-it task, it is critical for protocol compliance, and a part of project maintenance for the life of the study. Any time someone leaves the study team is a good time to go into User Rights and audit project access. Any users listed who have left the team, or are no longer listed on the protocol should be removed. Assess if responsibilities have changed for team members still working on the project, and adjust rights accordingly. Sponsorship for External User Accounts Additionally, if the the point person is sponsor for any external user accounts, he/she/ they should reach out to REDCap Team to transfer sponsorship to the new point person.Requirements
Applicable Track Required and Trainings and Forms by Track
![]()
Basics training for Project Builders
![]()
Survey training (if your project includes survey functionality) ![]()
Self-directed e-consent training if you will be setting up your project for e-consent (including Information Sheets)
![]()
Builder Agreement form and/or Supplemental Intake form prior to starting build Transferring Point Person to Another User
User Requirements
Eligibility Requirements
Training Requirements
![]()
![]()
Knowledge Transfer
Revisit User Management
Model of Support Key
Standard Support for Research
Self-Service for Research
Standard Support for Non-Research
The number one key to success is designating the "right" person to be the builder/point person for the project and supporting the time investment they will need to:
- Learn the software
- Familiarize themselves with our operations
- Build the project
- Train the other team members on how the project is built to capture data
In our experience working with study teams since 2007, the "right" person is usually a study coordinator or research coordinator, who is motivated to learn new technology, can collaborate with stakeholders to gather requirements, and will be working on the study for its duration. Interns and students, who may only be assigned to a study team for 2 or 3 months, can help build a project, but are usually not the best match to take the lead on a project build.