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 point person is the project team member who manages their team's REDcap project for it's lifespan, from creation, to the set up and design of the project, through real data collection, and to it's completion. 

For Supported Service 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).

Model of Support Key

Supported Service for Research

Self-Service for Research

Supported Service for Non-Research

Project Point Person Topics


Requirements

  • Build and/or manage the project build.
  • Adhere to help and support operations that correspond to the support track selected for the project.
  • Review the final set up and design of the project before moving the project to production.
  • Complete the following required trainings and forms for projects for each track type (see Model of Support Key):
Applicable TrackRequired 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


Expectations

  • Disseminate REDCap operations and requirements, reviewed in training, with the rest of the project team.
  • Share pertinent information with the project team about the model of support.
  • Coordinate or carry out user management for the project.
  • Train the project team regarding data entry workflow and data entry activities for the project.
  • Manage change in production.
  • Arrange for a handoff of point person duties (see below), in the event a new point person takes over.
  • Be the point of contact for email help.
  • Be available to attend drop-in sessions, as needed, for in-person help.
  • Comply with all regulatory requirements and institutional security and privacy policies that apply to the data you plan to collect.

Transferring Point Person to Another User

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.

REDCap training requirements

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.

Knowledge transfer

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:

  • What functionality the project uses:
    • For all projects:
      • How are records created or named?
      • Is the project longitudinal?
      • Are Alerts & Notifications used?
      • Etc.
    • For survey projects:
      • Are Automated Survey Invitations configured?
      • Is the Survey Queue utilized?
      • What Survey Settings are enabled?
      • Etc.
  • What the daily, weekly, or monthly operations of the project are.
  • Management operations like onboarding new team members.
    • What privileges or training would a new person need to begin working in the project?
    • Does the new user need a new role, or fit into an existing role?
  • Roadmap for the project.
    • Where is the project going?
      • It is in development and in need of further building?
      • Is it in production and need new functionality?

Revisit user management

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.