Monday, 12 August 2013

Assigning roles to Team members

In Quadrant, the role regards the ability to grant access and edit the online project space (this differs from responsibilities, discussed in the earlier blog,  which define the tasks team members are assigned to undertake the research project). You can assign your research team members/ administration officers/ stakeholders to any of these five positions:
  • Owner - E.g. Chief Investigator, PHD Supervisor. This person has full control and access to all elements of the project.
  • Officer - E.g. Project Manager, Project Officer. This person has most privileges and access, but cannot modify major details or close a project.
  • Worker - E.g. Research Assistant, Field Officer. This person can execute assigned workflow steps, add and edit participants but cannot affect project users. This is the day-to-day operations role.
  • Support Worker - E.g. Transcriber, Data Entry Assistant. This person can access predefined workflow steps and operations, such as uploading files.
  • Stakeholder - E.g. Project Board Member, Funding Representative. Stakeholders can access project meta-data such as number of participants in a workflow. Stakeholders cannot view any project files, participant information, or other Team members.
While these roles cannot be edited, you can easily change the role you have assigned to a team member at any time. Below is a list of permissions for each role.
Role Permission Chart
By assigning a combination of responsibilities and roles,  this gives added security to the project owner that sensitive data is handled in a ethical manner. If you have any concerns or require advice, please contact the Quadrant team.

Managing team responsibilities

Managing team responsibilitiesThis is a really great tool for two reasons; it assigns tasks and responsibilities based on your workflow steps to individual team members, and ensures internal data security between team members.  This means that team members will only see participants if they are within the workflow step they have access to and the project owner has the added security of keeping sensitive data available to only those team members who require it. I’ll discuss this in more detail below.

Assigning responsibilities

Responsibilities are tasks which are assigned to each step within a workflow. In the screen shot below you can see the description field I’ve include the tasks to be completed within each step.
image of workflow steps task description
You are free to construct the workflows and descriptions that best fit your project.

After designing your workflow, you can assign your team members to specific steps within the workflow which they will be responsible for. In the screen shot below, you can see different team members assigned to different steps. This means that team members will only see participant data when the participant is within a step a team member is assigned to.  As an example, the screen shot below displays the steps assigned to individual team members. You can see that User 2 has access to the Consent/Enrolment, Transcription and Completion steps. User 2 will only see participant data if they are within any of those 3 steps.
Image of workflow assignment to team members
Below is a screenshot from the view of User 2.  The workflow steps User 2 has access to are coloured in blue (Consent/Enrolment, Transcription and Completion).  Of the 21 participants in this study, User 2 can only view the 7 participants within the 3 steps that User 2 is assigned to. This includes 0 in the Consent/Enrolment step, 4 in the Transcription step and 3 in the Completion step. The remaining participants are within other steps and cannot be viewed by User 2.
Image of participants within a workflow step
Remember that when assigning responsibilities, you are restricting team members access to edit the research data.  This differs from assigning a role which is in my next blog "Assigning roles to team members," which talks about accessing and editing the online project space.

Tracking your Participants - Participant Workflow Status

At Quadrant we are always exploring ways to simplify the process of managing your participants and projects by making Quadrant easier and intuitive. Following your feedback we are excited to announce the release of the Participant Workflow Status feature.  This feature makes it easier for you to track your participants and easily view their status in regards to the workflow. 

The Participant Workflow Status feature comes in handy if you have a large list of potential participants that you choose to recruit from specific participant criteria. It is also handy to record participants that are unsuitable for enrolment (and to make sure you don’t accidentally contact them again!) and to record participants that have declined or cease participation in your research project.
The Participant Workflow Status feature provides you with five ways of describing your participant in relation to your research project. They are:

  • Start Participant details have been imported into Quadrant but a participant has not been selected to start a workflow. e.g. You have identified and have or a list of potential participants but wish to search and sort on specific criteria prior to contacting the participants before the enrolment/ consent process begins.  For example your research project may explore outcomes of an intervention program across different regions. Using this feature will allow you to easily sort participants based upon their demographic and begin enrolment of participants at each region in a stepped process.
  • Active Participant has started a workflow. E.g A participant has been enrolled and is in the process of undertaking your research.
  • Exited WorkflowParticipants that have started a workflow but do not wish to participate further in the research.  The function is normally participant initiated, e.g. a participant requests not to be involved or consents and later withdraws from the research..  If required, you can still delete and remove all identifying information of a participant. 
  • Dropped Workflow – Participants that have started a workflow but is known to the research team that they are not suitable or cannot complete a research workflow. This function is team- member initiated – e.g. the research cannot contact a participant, or participant does not meet selection criteria. 
  • Completed Workflow Participants have started and finished all workflow stages. E.g. A participant finishes all stages.

Use the Participant Workflow Status features to troubleshoot problems with enrolment and your project.

By recording Participant Workflow Status you can begin to describe your research project and troubleshoot problems in participant recruitment, enrolment or attrition.
As the Workflow Status is recorded against the participant, Workflow Steps and Team Member you can start to get insights such as:
  • Is there a Workflow Step which is causing participants to cease involvement in your project? Is the process too time consuming, confusing or uncomfortable for the participant?
  • Have more participants completed the Workflow when assigned to a Team Member?
  • How many participants have completed compared to the participants that were enrolled. Was that expected? Do you need to consult the accuracy of your contact details or explore your recruitment process?
Try it today. You can find the Participant Workflow Status feature in the All Project Participant page and the My Participant Page.