Topic: Adding and Managing Users Within a Host and its Underlying Studies
The User Manager is where users within a given host are centrally managed, regardless of which studies they belong to within the host account.
Every user has access at two separate levels:
Host Account level - Think of this as the global list of users available to assign to all underlying studies.
Study level - This is where you assign users to specific studies, after they already exist on the host.
This article covers user management at both the host and study levels.
Adding Users at the Host Level
Prerequisite
The user has access to Host level permissions for the User Manager
Open the User Manager screen from the Host settings menu.
Mobile App:
This opens the table of users with access to edit existing user or add new ones
New users can be added by tapping the button at the top of the list.
To edit an existing user, tap “More” or tap the row itself.
Host Role
The role selected is the Host level role, not the study role. The user's site and study role are managed separately at the study level.
Most users at the Host level will have the role of “Limited”. Read more here about Roles at the host level.
Additional information about other properties that can be defined for users is shown below. Those properties will not be available until after a user is first saved.
TMF User
Users who will use the Trial Master File (TMF) in any capacity should be given access here. This will make the user displayed as an option when assigning TMF tasks.
The TMF attribute is accessed when adding or editing an existing user. Tap on any user to open the details for editing.
CC Credentials E-Mail
Other email addresses can be included for reset notifications to be sent to. The primary purpose of this is for users who are unable to receive emails from TrialKit due to their organization IT rules that are blocking the emails.
Since emails are required for secure login access, the "CC" option allows an Administrator to enter a separate personal email address for that user which might not get blocked. Alternatively, the Administrator can enter their own address for the purpose of providing the secure login link manually to the user who is not able to get it to their own inbox.
Email addresses can be added via a comma separated list, if multiple are needed.
The email address(es) entered into this field will not be saved. It will only be used for the current instance of sending the user’s reset link. In other words, enter the CC email address and then tap the Reset button. An email will separately be sent (not cc’d) to each email address listed, including the primary user address. Resetting the user’s password again later will not send the reset to that same list unless it is entered again.
Batch Uploading Users
A convenient way of adding users is available where a CSV-formatted list of users can be uploaded all at once. Additionally, they can be immediately added to a study and site with a specified role in the same step. This is a big time saver over manually adding users one by one, as described in the section above, and then having to manually designate each user to specific sites.
Web Browser:
This will open the device file manager to choose a CSV file for uploading. On an iOS device, that file must exist in the iCloud TrialKit app folder.
The file must be set up in the following way, with no column headers:
Column A: User first name
Column B: User last name
Column C: User email address
Column D (optional): Study ID - The study ID to add the user to, found in the host Study Manager
Column E (optional): Study role - The name of the study level role to give to the user
Column F (optional): Site ID - This should be the "DB ID" for the site as found in the Site Manager. This will be the site to make the user a member of, with the role specified in the previous column.
Column G (optional): TMF user - this makes the user a TMF user
Example:
Important Factors to Note for Batch Importing Users
All users will be given a host-level role of No Access. Not all users need to have all columns defined. The only required columns are the first three to add the users to the host.
Ensure duplicate emails are not used and the study role text matches the name of the role from the study configuration.
New user emails will be added to the host. Existing emails will be updated to match the details dictated by the file (study, site, and role) - which means an existing user's membership or role could change if it already existed in the corresponding study. All changes made to users will reflect in the site/user audit report.
Reminder
Please adhere to TrialKit’s policy (see Terms of Use) of only uploading user email addresses that are both valid and have given implied permission to be added to the system. This helps the system control spam and bounced email notifications to its users.
Managing Users at the Host level
The following properties can be defined/edited for each user.
User Last Name
User First Name
User Email Address
Role (Host-level role)
This is the Host-level role. "No Access" simply means the user has no access to Host level functions. The study role will be separately assigned (read here)
Studies - Lists all studies the user is a part of. Read here on how to add a user to a study.
Status - By default when users are added, they are active. Tapping the status will suspend the user and show as “Suspended”. This is helpful for disabling user access without removing them from the account or studies, for future traceability of their study involvement.
User Profile - This is an optional form that can be customized and filled out to collect specific data on individual users. Read more here.
Send Sign-In Information - Button to send the user a sign in reset link to their inbox. This is only necessary for new users so they know they have been added. Users can also do this on their own by using the Forgot Password function on the sign in page.
Make sure users have white-listed TrialKit as a safe sender
Sign-in information and other system emails will come from the following email addresses/domains:
Be sure to add that address to the white list in your organization's email system
Edit - Button to update/edit the user’s information.
Delete - Button to delete the user from the host account and all studies on that host which they are a member of. Deleting users is not the recommended approach, as it makes traceability more difficult in the future if that user was part of any study activities. Suspending users, or removing them from the study are two alternatives to removing them entirely from the Host.
Adding and Managing Users at the Study Level
Prerequisite for managing study users
Access to Study Configuration, Configure Sites and Users
Web Browser:
Under Study Configuration settings, select the Sites and Users tab. Go through the following drop-downs to add users to appropriate sites with the appropriate study roles.
Site: Select which site to work with. The list of options here comes from the Site Manager.
User: Select which user to add. The list of options here comes from the User Manager. The user's email is included in the name drop-down to help distinguish who the user is.
Role: Select the role to assign to the user. The list of options here comes from the Role Security settings. If only one option appears, it's because the user selected already belongs to another site with a specific role. Users can only have one role in a study.
Add User to Site: Select this button to add the user to the list directly to the right.
Save Study Configuration: Select this to save changes.
Mobile App
The mobile app makes managing users even easier, by allowing everything to be done from one place.
Under Study Configuration settings, select the Site/User Manager. Follow the annotated descriptions below the image.
Choose a role that new users will get. If a user is already part of one of the sites as another role, adding them to a new site will automatically change them to the new role that is set at the top of the screen. If you aren’t sure if a user is part of a site already and does not want to tap through each site to find them, reference the site by user report.
If a user is missing from the user's list, they can be added to the Host User List here without needing to navigate there to add them first.
By default, the user list only shows users who have been made available to the study within the Host User Manager. This makes user management easier to focus on only users applicable to the current study. If you don’t see a user in the list and want to make sure the full list of Host users doesn’t already contain that user, then tap the box to display all of them. Users in red are not available for the study but can be added to the current study by simply dragging them to a site.
Use the search box over any of the lists to search that list (name or email). Searching the user list will also filter the site list for all sites which that user is part of.
Drag any user in the list over to the site they need access to. Remember, Admin users only need to be added to one site if their role has permission to access all subjects.
Tap a site to display the member users/roles at the bottom.
Tap any user to change their current role. This will change their role on any sites they are part of.
Note
At least one user must belong to a site for that site to be a part of the study, but there is one other important step to take so the site is accessible from the subject manager: The site must be added to a study version (read how within version management)
Deleting a User From a Study
To delete a user on the Web Browser, use the red 'X' icon next to each user.
On the Mobile App, swipe from right to left on the user’s row in the bottom table.
When deleting users belonging to multiple sites - this must be done for each site the user belongs to. An alternative to this is suspending the user at the Host level - which will make it so they cannot access the Host account at all.
Following are some helpful reports for viewing user site membership and audit logs of user or site membership changes over time:
Site By User Report
The Sites and Users Report provides a comprehensive listing of all the users on a given study broken down by site. This is a helpful place to reference user membership and roles, along with other information like last sign-in.
Prerequisite: User has Access to Site by User Report.
This should only be granted to Study Administrators as it shows all sites and users.
It can be accessed via the Web Browser:
Tip
The full list can also be exported to see additional details, including Subject ID for users that are Participants.
Common User Manager Management Questions (FAQ)
Question: When a user is no longer part of a study, we receive a request to remove the user from the study database. Is it better to suspend the user and remove them from all study sites, or to delete the user completely? What are the pros and cons of both ways?
Answer: The best thing to do is suspend the user if they are only part of one study. Deleting the user from the site is also an okay alternative, but that will make it more difficult later on to see which users were part of which sties. If you choose to delete a user from the site, you would have to reference the audit trail to see if a user was ever part of the site / removed from the site. By suspending the user, everything stays as is, but the user just loses access to that Host account when they sign in.
Question: How do I prevent the Administrator from accessing site date?
Answer: It’s usually recommended that anyone with an Administrative role should have access to everything, because at some stage, someone needs to be the privileged owner of the database with full visibility. Administrators can be prevented from modifying site data, but it’s usually recommended to keep view access in order to provide study support and export data. Crucial Data Solutions support desk cannot serve a study Administration role on behalf of the customer.
The best approach to this, is to have a “Sub-Admin” role that is a copy of the Administrator permissions, but with two exceptions: The role is a Site type role, and does NOT have access to all subjects.
Based on that, any user with a sub-Admin role will need to be individually added to any/all sites that they are allowed to see, but they will still be able to serve Administrative functions with regard to managing sites, study configuration settings, and form building, etc.
As with any changes to user site membership or roles and permissions, these settings are audited over time, so the Administrator could verify if a specific user with their given role ever gained access to site data during the course of a study.
The Site by User report provided a list of which users belong to which sites. Note, anyone with a role that has Access to all subjects will have visibility of all sites regardless of which site(s) the user is directly a member of.
The Site/User Audit report provides a history of changes to users’ site membership over time
The Role permissions audit is how to track changes to role permissions over time.
Requesting User Account Deletion
Host Administrators are responsible for user account management for the users on their own host. Users should first try to request account deletion from their Administrator.
If TrialKit support receives notices to remove a user’s account at that user’s request, by regulation, Crucial Data Solutions must comply. However, our team will attempt to first contact/notify the host Administrator.
Users can submit request for account deletion by emailing support@trialkit.com