Within DatStat there are two types of Participant Lists: Master and Derived.

Master Participant Lists

Master participant lists hold the Global Pool of Participants that may be selected for participation in multiple Studies or Surveys.  For example, you may want to maintain a master list of all of the patients who come into your clinic.  Some of these patients may never be invited to take a survey, but regardless you want to store and maintain information about them on a list.  Alternatively, you may have a list of participants who you want to take your survey, and every single person on that list will be invited to take your survey.  In either case, what you have is a Master list.

Derived Participant Lists

A Derived list is a copy from the Master list of a subset of Master list participants.  For example, a particular study may only need male participants.  From the Master List which contains both males and females, you may want to select only the male participants for a particular survey or study.   This subset is a “Derived” list – it is derived from the master list.  It does not remove the participants from the master list, rather it copies them from the master to the derived list.

NOTE: Study creation in DatStat Discovery requires a Derived List.

NOTE: All Customers upgrading from a 4.x version of DatStat Illume will find that the Global Participant List that was visible to Administrators within the Web Console will be converted to a Master List, and all existing Participant Lists will be converted to Derived Lists of that Master List.

Creating a participant list is a two step process.  You must first define the participant list, which creates a table.  The second step is to upload your participants into that table.  The steps below focus on how to define the participant list.  In another area of Academy you can access information on how to upload your participants into the table you create.

Creating a Master Participant List

1. Log in to Enterprise Manager as either the Local Administrator or a User with sufficient permissions to work with Participant Lists and the projects they are in.
2. Expand the appropriate Project
3. Select the Participant Lists icon
4. Select Take Action/Add Participant List
5. Enter the Participant List Name
6. Select the Project where the List will reside
7. Select ‘Master’
8. On the Participating Sites Tab, select the Sites and Site Groups to be available for all Derived Lists of this Master List
9. Click Save and OK

Creating a Derived Participant List

1. Log in to Enterprise Manager as either the Local Administrator or a User with sufficient permissions to work with Participant Lists and the projects in which they are located.
2. Expand the appropriate Project
3. Select the Participant Lists icon
4. Select Take Action/Add Participant List
5. Enter the Participant List Name
6. Select the Project where the List will reside
7. Select ‘Derived’
8. Select the Master list it is associated with
9. On the Participate List Columns Tab, select the Custom Properties that will be inherited from the Master List
10. On the Participating Sites Tab, select the appropriate Sites to be used if desired. NOTE: Sites must be created in the Enterprise Manager by an System Administrator prior to this step
11. Click Save and OK

Editing a Participant List

1. Log in to Enterprise Manager as either the Local Administrator or a User with sufficient permissions to work with Participant Lists and the projects they are in.
2. Expand the appropriate Project
3. Click on the Participant Lists link
4. Click the Edit Participant List icon for the list to edit
5. User can modify the Name and Project of the Participant List
6. User may choose to enable the use of Relations in the Participant List
7. If Custom Properties are available the list of inherited properties can be modified
8. Click Save and OK to commit any changes

Using Relations in a Discovery Study

When a Master or Derived Participant list is created Users may Add relations, and contact attempts made with those relations, from the participant summary view.

Relations are different people who may have a relationship to the Participant. For example, some studies might have individuals (father, aunt, teacher, etc) who will be contacted to help locate the participant for a follow up interview if their contact information changes.  The Relations field is a scale value list that is viewed as a drop-down menu in the Relations panel when adding to/updating relations information for a Participant (e.g. 1=father, 2=sister, etc.). Relations must be created and enabled in a Master list in order for them to be enabled in the Derived List.

Enabling and Defining Relations In a Master List

1. Log in to Enterprise Manager as either the Local Administrator or a User with sufficient permissions to work with Participant Lists and the projects they are in.
2. Expand the appropriate Project
3. Click on the Participant Lists link
4. Click the Edit Participant List icon for the list to edit
5. Check Uses Relations
6. Click on the Participant Relation Types tab
7. Click Add New Scale Value
8. Enter the Code and Name for the Scale Value – For instance 1 = Father  – Value= numeric and Label = text
9. Continue adding values until complete
10. Click Save and OK to commit

Selecting Relations In a Derived List

When creating a Derived List from a Master List with Relations, Users are able to select the Relations to make available in the Study.

1. On the Edit Participant List screen
2. Check Uses Relations
3. The defined relations from the Master List will be displayed
4. Check the Relationships that should be enabled
5. Click Save and OK to enable the selected Relationships

 

 

Because Derived Lists are created from Master Lists, information can be “passed down” from a master list to a derived list.  Another way to say this is that the derived list can “inherit” information from the Master list.    This inheritance concept allows information to be shared from the master with the derived.  It also ensures that as information is updated on the dervied, that this information can roll back up to the master list.
When a Derived List is created, most Participant Properties retain the value and the scale from the Master List.  Not only is the value and scale “passed down” to the Derived List, but if the value of these properties is changed on the Derived list, the new value will roll up to the master list, and will then roll back out to any other lists that derive from the master.

All Custom Participant Properties are inherited in this manner.

Most of the Standard Participant Properties are inherited in this manner aside from the exceptions listed below:

1. The following properties do not inherit their value from the Master List:

DATSTAT_PID
DATSTAT_CREATED
DATSTAT_CREATEDBY
DATSTAT_LASTMODIFIED
DATSTAT_LASTMODIFIEDBY
DATSTAT_CASEOWNER

2. The following property does not by default inherit the values from the Master List, but the User can edit the Derived List indicating the Sites and Site Groups that will be inherited and show in this Property List:

DATSTAT_SITE – Unless Set Site from Master List, is checked when creating a Derived Participant List

 

3. The following property defaults to the value on the Master list, but if it is changed on the Derived list, the value from the derived list does not roll up to the master list:

DATSTAT_ALTPID (but it does default to the MASTER list’s value if none is specified)

 

4. The following properties default to the value on the Master list, and cannot be changed on the Derived list:

DATSTAT_MASTERPID
DATSTAT_MASTERALTPID

 

5. The following properties are unique to the Derived List – they do not exist on a Master List as they only exist when associated with a specific study:

DATSTAT_STUDYARM
DATSTAT_EXITDATE
DATSTAT_EXITREASON
DATSTAT_EXITCOMMENT

 

 

 

When a new participant list is created, the Enterprise Manager builds out a table for that participant list, and that table comes with a set of already built-in columns.  These already built-in columns are a combination of commonly used participant fields (e.g. contact information, gender, DOB) and system variables that are automatically populated (e.g. the date/time the participant was uploaded, the date/time the participant was last modified).

There are 38 Built-In properties, and they can be viewed by:

1. In the Enterprise Manager click Participant Lists
2. Find the participant list on the right pane, and click View Participant List details
3. Click on the Built-In Properties tab

Editing Standard Participant Properties

Every participant property has attributes that define it, similar to the way survey variables have attributes.  You can alter some of the attributes of a participant property, but some attributes cannot be altered.  The attributes that cannot be altered are:

1. Name
2. Data Type
3. Display Type

Users may edit the following fields of a Standard Participant Definition:

1. Label
2. Property Group
3. Order in Group
4. Error Message
5. Description
6. Required
7. Disabled
8. Data Validation
9. User Access Exclusions
10. Scales – the values and the labels

To Edit a Built-In Participant Property:

1. Must be logged in as a User with the Administrator and/or Study Administrator Role for the Study/Project or System
2. Click on the Enterprise Manager Link in the upper right corner of the Discovery interface if not taken directly there at login.
3. Expand the Project where the study is located
4. Click on the Participant Lists link
5. Click on the Edit Participant List Columns Icon
6. Select the Built-In Property tab
7. Click on the Edit Property icon in the row of the Property you wish to edit
8. Once you have finished Click Save

NOTE: Properties added to a Derived list do not get automatically created on the Master List. 

 

Custom Participant Properties may include any information users know or want to capture regarding Participants that is not already captured by the Built-In Participant Properties.

Participant List Property Limits

• A Master Participant List can have a total of 250 properties per list.  These properties can be of any Data Type.

• A Derived list has the same requirements but can also inherit all of the Master Participants Custom Properties.  Thus if the master list has 250 properties, these 250 properties can be inherited to the derived list, and an additional 250 custom properties can be created on the derived list, for a total of 500 properties.

Adding a Custom Participant Property

1. Must be logged in as a User with the Administrator and/or Study Administrator Role for the Study/Project or System
2. Click on the Enterprise Manager Link in the upper right corner of the Discovery interface if you haven’t been taken directly there at login.
3. Expand the Project where the study is located
4. Click on the Participant Lists link
5. Click on the Edit Participant List Columns Icon
6. Select the Custom Participant Property tab
7. Click Take Action/Add Participant List Column
8. Enter the appropriate information and Click Save.

 

Participant Property Fields/Attributes

The Property Fields are the same for both Standard and Custom Participant Properties.

NOTE: * denotes a required field

Name* – The Name of the Participant Property

The requirements for naming Participant List Columns are similar to those for naming Surveys and Variables.

The following is a list of the requirements:

• 2-128 characters in length
• Starts with a capital A-Z or 0 – 9
• Following characters  can be A-Z, 0-9, underscore (_), hyphen (-), or period (.)
• Cannot use DATSTAT as this is reserved for Standard Properties

Data Type* – Defines the way the data is stored

Possible Data Types:

• Date – A valid calendar date, including day, month, and year. E.g. 12/11/2005. Dates that don’t exist, like 02/30/2004, are not valid
• Date/Time – A valid date and time, including year, month, day, hour, minute, and second. E.g. 12/11/2005 12:51;17 pm
• Decimal – Numbers with both whole and fractional component. E.g., 3.14, -299.173 – The precision can be up to 28 places.
• Float – A float is a decimal number in which you can put the decimal anywhere in the number.  This is distinct from “decimal” in that a decimal requires that you specify a precision and scale. The scale is the total number of digits including decimals places; the precision is the number of places right of the decimal. Decimals allow more specific and precise values, while floats are approximate values.
• Integer – Numbers without a decimal component. E.g., 21, 55000, -211
• Text
• Time – A valid time, including hour, minute and second. E.g. 12:51:17 pm
• True/False – A simple 0 or 1 value. 0 traditionally represents No or False, while 1 represents Yes or True. Illume allows you to reverse the traditional meanings if you wish. All checkbox items are of this data type, since a checkbox can have only two states (checked or not checked).

Label* – Text the User sees when Adding/Editing a Participant, and in Data Grids once a participant is uploaded

Display Type* – The Control that is output when Adding/Editing a Participant

The options are Pop-List, Radio Button, Text Box, , Check Box, Commentary, and Hidden.

Only when the options Drop-Down and Radio Button are selected will the Scale tab become enabled.

Property Group* – The Group Name of the Fields.  Specifying a Property Group allows Users the ability to group Properties together, making them easier to find.  In addition, when viewing a Participant, Property Groups are presented in alphabetical order, so putting critical properties in an “early” Property Group ensures they will be presented at the top of the screen. DatStat recommends using numbers as a prefix for group names so that the order of your groups is organized the way you prefer, for example 01: Patient Contact Information 02: Patient Study Progress, etc)

NOTE: Property Group names are Case Sensitive – They must be typed exactly the same for each Property in that Group or there will be a separate group created (i.e. “Consent Variables” is not the same as “Consent variables”).

Order in Group* – Within a Property Group, this is the order in which a particular Participant Property will be presented.

NOTE: Order is not enforced but is respected.  In other words, if you have three properties in the same group marked as “Order in Group=1”, an error will not be presented.  Rather, Discovery will present those properties in random order as the first three properties.

Parent Column – Used to identify the Parent for a Dependent Property

Error Message – Error Message that will display if the property is entered incorrectly when Adding/Editing a Participant. For example, if integer data type is specified for a property and non-integer data are entered when editing a participant, this error message will appear and will prevent the User from saving that participant until the data are changed.

Default Value – If the property uses a scale, you may define that the property defaults to a particular scale value.  The Default Value must match one of the scale values if they are defined

Description – A text description of the Participant Property

Required? – Check box to make this a required property.  Required means that all participants must have a value for this property from the moment they are uploaded.

Disabled? – Check box to remove it from view during Adding/Editing a Participant

Allow Bulk Update? – Check box to allow a User with sufficient Privileges to use the Bulk Update Action for this Property value.

Unique? – Check box which will require that the Property value is unique across all Participants in the Study. It will prevent duplicate entries by presenting an error message. This is typically used for ID and Email Address fields.

Indexed? – Check box which creates a database index on this Property field to increase speed of search/query.

NOTE: If Indexing is used too frequently it will decrease over-all performance of the system.

Data Validation – Specifies Formats and Bounds for the Property to ensure the data are correctly inputted.

• Max. Length – Maximum Number of digits for an integer
• Min. Value – Minimum Number of digits for an integer
• Decimal Precision
• Validation Pattern (Regular Expression)
• Max. Value
• Decimal Scale

 

Scale Tab

The Custom Participant Properties can be given scale values by Clicking on the Add New Scale Value link in the Scale Tab. The Data Type must be Integer and it has to be a drop-down/poplist – you can enter numeric or text as the value/code

Code – Scale Value for that possible response

If a Numeric data type is chosen then it will be Numeric

If a Text data type is chosen it can be textual

Label – Visible Text associated with Code

NOTE: Scale Values must match the defined Data Type.  e.g. Use 1,2,3 if Integer was selected 

 

After the first code and label has been added, click “Add New Scale Value” to add another.  Continue this process until all have been created.

User Access Exclusions

Participant Properties can have Exclusions set to give Full, Read Only or Hidden access to Users or User Groups.  By default, all users have read/write access to all properties.  Thus, exclusions can be set for a user or user group to make a property read only, or entirely hidden.  This is set property by property – it is not possible to set exclusions in bulk.

A Participant Property may have multiple Exclusions applied. See the Section on User Access Exclusions for more details

A Note on Date and Time Data:

DatStat Discovery uses Microsoft’s .NET DateTime object to store dates and times. The .NET DateTime object can represent dates between 12:00 a.m. January 1, 0001 CE and 11:59:59 p.m. on December 31, 9999. Illume considers dates outside of this range to be invalid.  Non-existent dates are also invalid. For example, February 29, 2005 is invalid because 2005 is not a leap year. Participant must enter dates or times in a format that .NET recognizes. In general, for the United States locale, dates in the following formats are valid:

• mm/dd/yyyy  This is a 2-digit month, followed by a slash, followed by a 2-digit day, followed by a 4-digit year. E.g., 09/16/2006

• Monthname Day, Year E.g. January 25, 2005

Other date formats will also work in the US. You should, however, suggest a format that you know will work in either your question prompt or in the question label. For example, a prompt that suggests a valid format would be: Please enter your date of birth (mm/dd/yyyy): Illume and .NET recognize both 12- and 24-hour time formats, though Discovery may ignore the seconds. The following time formats are valid in the US locale:

• hh:mm This is a 24-hour time format. E.g. 23:15

• hh:mm am/pm This is a 12-hour time format. E.g. 11:15 pm

.NET uses the same standard set of date and time formats that other Microsoft products use. This means that any Date, Time, or Date/Time format produced by an application like Microsoft Excel, Access, or SQL Server will work in Illume. Use the Date data type only for variables that must include a day, month, and year. If your variable requires only one of these values (day or month or year), choose the whole number or text data type. Choose Date/Time data type only for variables that require a day, month, and year value with an optional time value.

 

Dates, Times, and Localization

Discovery and .NET use the locale settings of the Illume server to determine dates and times. This can cause some confusion if a survey is not designed correctly. For example, if you are administering a survey to participants in both the US and the UK, you should be aware that the two locales use different date formats. A US participant entering 06/12/2006 will mean June 12, 2006, while a British participant entering the same thing will mean December 12, 2006. If the survey is running on a server whose locale is set to EN-US (English, United States), the date will always be interpreted as June 12. If the server’s locale is set to EN-GB (English, Great Britain), the date will always be interpreted as December 6. This will be a problem if your question includes a minimum and/or maximum date. The British User or the US User may not be able to get past the date question simply because the participant and the server do not agree on what the date means. One way to avoid date/time problems caused by local differences is to break dates and times into separate questions, each of which is of type whole number. For example, instead of asking for a participant’s birth date, ask for his or her year of birth, then month of birth, then day of birth.

 

Adding a Participant Property after initial list creation

When testing or running a study, Users may realize that a Participant Property is needed that was not already created.

Users must first determine is if this Property should be created at the Master or Derived list level.  If the Master list feeds into multiple derived lists OR information is being captured on participants at the master list level, not within the Discovery Study interface then add to a Master.   If the Property is only relevant to the specific study to which the participants are enrolled, then the Property should be created at the Derived list level.

 

Master Level Properties used in a Derived List

1. Log in as a User with the Study Administrator Role for the Study/Project or System in Discovery/Illume
2. In the Enterprise Manager screen expand the appropriate Project
3. Select the Participant Lists icon
4. Select the Edit Participant List Columns icon from the appropriate row of Participant Lists
5. Follow the steps above to add the property.
6. If the Master List is used in the Study you are finished
7. If there is a Derived list then continue
8. Click on the Edit Participant List icon
9. Check the Added Property in the Inherited Participant List Columns section
10. Click Save and OK

 

Derived List Properties not used in Master List

1. Log in as a User with the Study Administrator Role for the Study/Project or System in Discovery/Illume
2. In the Enterprise Manager screen expand the appropriate Project
3. Select the Participant Lists icon
4. Select the Edit Participant List Columns icon from the appropriate row of Participant Lists
5. Follow the steps above to add the property.
6. Click Save and OK

 

 

 

When a participant list has custom properties, users have two options for creation of those properties:

1. Prior to uploading participants, built out each custom participant property on the participant list.  The advantage of doing so is that by building out each property and its attributes, you can be assured that when participants are uploaded, that the participant information in that upload file meets the requirements of the properties you created.  For example, your custom participant property may have a scale of 1=male, 2=female.  When you upload your participant list, you may have an erroneous “3” in the list.  By creating your property in advance of the flat file upload, you can ensure that the enterprise manager will catch this error and flag it during the upload.
2. The second option is to simply add the custom properties to your participant list flat file without creating them in advance.  This is a faster method, in that there is no effort involved other than adding the columns to your flat file.  When you upload that file, the Enterprise Manager will automatically create those custom properties.  The disadvantage to this method is that when your custom properties are created, they are created with a data type of text, and display type of text box.  Given this, the columns could contain all kinds of erroneous data, but all data in the column will be accepted without any rule/validation enforcement.

Uploading into a Master List

1. Create a Tab-Delimited text file that has the Custom Properties as the Column Headers
2. On the left pane of the Enterprise Manager select Participant Lists
3. On the right pane find your participant list, and click View Participants
4. From the Take Action menu select “Import Participants”
5. Browse for your file and select it.
6. Select an import option, e.g. “Add participants that do not already exist”
7. Check the “Create participant list properties that do not exist” check box.  It is this text box that tells the Enterprise Manager that you want it to create a custom property for any property “that does not exist”, i.e. that is not already a built-in property.
8. Click Save and OK
9. Go into each property and modify the Data Type and Display Type if desired

NOTE: These Properties can now be inherited by Derived List

Uploading into a Derived List

To upload Custom Properties into a Derived List follow the same steps as uploading to a Master List.

Keep the following in mind:

• If the Property does not exist in the Master List it will be added to only to the Derived List
• If the Property is in the Master but Disabled in the Derived List, it will now be Enabled in the Derived List

 

 

Participant Properties can have Exclusions set to give Full, Read Only or Hidden access to Users or User Groups.

A Participant Definition may have multiple Exclusions applied.

 

Steps

1. Must be logged in as a User with the Administrator and/or Study Administrator Role for the Study/Project or System
2. Click on the Enterprise Manager Link in the upper right corner of the Discovery interface if not taken directly there at login.
3. Expand the Project where the study is located
4. Click on the Participant Lists link
5. Click on the Edit Participant List Columns Icon
6. Select the Standard Participant Definition tab or Custom Participant Definitions tab
7. Click on the Edit Property icon in the row of the Property you wish to edit
8. Select the User Access Exclusions tab
9. Click Take Action/Add New User Exclusion
10. Select the User/User Group
11. Select the Exclusion Type
12. Click Save and OK
13. Repeat if multiple Exclusions are needed for the Definition

 

NOTE: If a User Group is given one access to a Definition but a user within that group is given different access, the access given to the user will always supercede the group access.

 

Dependent Definitions

Parent Definition and Dependent Definition on the Same Participant List

A Dependent Definition is a Participant Definition whose scale is relative to what is selected in the Parent Definition.  For example, an “Eligibility” Participant Definition might be created with a scale of 1=Eligible and 2=Ineligible.  A Dependent Definition relative to this Property might contain reasons for eligibility or ineligibility.  Dependent on the value for the Parent Definition, the scale on the Dependent definition will be altered, showing only those values meaningful given the selection.

Creating the Parent Column

1. Follow the steps for Creating a Custom Participant Definition and using the Scale Tab.
2. Save the Definition

 

NOTE: The Definition MUST have a Display Type = Drop-Down List

Creating the Dependent Definition

1. Follow the steps for Creating a Custom Participant Definition or use an existing Standard Participant Definition

NOTE: The Definition MUST have a Display Type = Drop-Down List

2. In the Parent Column select the Parent Column created above

3. A message will appear, click OK, the Scale Tab will disappear
4. Save your Custom Column and Click OK
5. Click on the Edit Participant List Column for the one you just created.
6. Select the Scale tab
7. Use the drop-down to select the first value
8. Click Add New Scale Value
9. Enter the Code and Value, repeat as many as needed
10. Select the next value from the drop-down and repeat

NOTE: Each code must be unique even between values in the drop-down

11. When finished click Save and OK

 

Parent Definition on a Master List and Dependent Definition on Derived Participant List

Creating the Parent Column in Master List

1. Follow the steps for Creating a Custom Participant Definition and using the Scale Tab.
2. Save the Definition

 

Creating the Dependent Definition in the Derived Participant List

1. When creating the Derived Participant List, select the Parent Definitions from the Master List to Inherit
2. Select the Edit Participant List icon for the List just created
3. Select the Edit Participant List Column for the inherited Parent Column
4. Click the Scale tab
5. Select the Master Scale Items to be used in this Derived List and Click the Add button in the center of the screen
6. The items should now appear in the right column
7. Click Save and OK
8. Follow the steps for Creating a Custom Participant Definition or use an existing Standard Participant Definition

NOTE: The Definition MUST have a Display Type = Drop-Down List

9. In the Parent Column select the Parent Column from above
10. A message will appear, click OK, The Scale Tab will disappear
11. Save your Custom Column and Click OK
12. Click on the Edit Participant List Column for the one just created.
13. Select the Scale tab
14. Use the drop-down to select the first value
15. Click Add New Scale Value
16. Enter the Code and Value, repeat as many as needed
17. Select the next value from the drop-down and repeat

 

1. Login to the DatStat Gateway as a User with the Study Administrator Role for the Study/Project or System in Discovery/Illume
2. In the Enterprise Manager screen expand the appropriate Project
3. Select the Participant Lists icon
4. All of the Participant Lists for that Project will be listed in the Table

 

Edit Participant List – Edit the List Name, Project and Use of Relations

 

View Participants – Displays the Participants that are members of that list

 

Edit Participant Definitions – Displays both Standard Participant Definitions and any Custom Participant Definitions that may have been created

 

 

 

Participants can be added to a Derived list directly from within a study.  This will automatically add them to the Master Participant list that the Derived list was originally created from. Participants can be added to a Master Participant List or Derived List from within the Enterprise Manager. Participants may be added manually, one at a time, or uploaded, in mass, with a tab delimited file.

 

Manually Add New Participant

To manually add a new participant to a Participant List:

1. Log in to the DatStat Gateway as a User with Participant Management ability
2. Navigate to the Enterprise Manager
3. Expand the appropriate Project
4. Select Participant List
5. Click on the View Participants Icon in the row of the appropriate Master or Derived Participant List
6. Select Add New Participant from the Take Action drop-down
7. Enter all of the appropriate Participant data in the Standard Participant Properties tab.
8. Add any additional information in the Custom Participant Info tab.
9. Select multiple Case Owners from the User Access tab
10. Click Save and OK.

 

NOTE: Make sure to select the appropriate Study Arm for the participant if this participant should be enrolled in a Study.

Importing Participants from a List

A list of participants can be imported in bulk into the system using the Import Participants option.

Start by creating a Tab Delimited Text file where the Participant Definition names are the column headers.

To Import a list of new participants into a Study Arm, take these steps:

1. Log in to the DatStat Gateway as a User with Participant Management ability
2. Navigate to the Enterprise Manager
3. Expand the appropriate Project
4. Select Participant List
5. Click on the View Participants Icon in the row of the appropriate Master or Derived Participant List
6. Select Import Participants from the Take Action drop-down

7. Use the Browse button to select the Tab Delimited Text file.
8. Select the desired Import Options
9. If using this list to add Custom Participant Definitions check the “Create participant list properties that do not exist” check box
10. Click the Save button
11. There will be an update either telling you of a possible error or how many participants were successfully imported.
12. At the Participants Updated screen click OK

 

NOTE: If the file does not contain information for all Required Properties an error message will be presented.  It will only upload the Participants that have data for all Required Properties.

 

Edit Participant

Users may edit Participant Definitions by clicking on the Edit Participant icon from any data grid.

 

Clicking on this icon will bring up the Edit Participant form.

 

Make the appropriate changes and click the Save Changes button.

 

A Master Participant List can be used to spawn multiple Derived Lists for different Surveys or Studies.

In this case Participants would be added to the Master List and then add a selected group to a Derived List.

 

The following steps assume a Derived List was already created.

 

Steps:

1. In the Enterprise Manager navigate to the desired Master Participant list.
2. Using Filters, identify the Participants which you would like to add to the derived list
3. Use the Select All check to mark the Participants
4. From the Take Action drop-down, select Add Selected Participants to Derived List
5. Decide to either create a new Derived list or use an existing one
6. If it is an existing one, select from the available lists

7. Click on Save and OK

Optional – If Creating a New Participant List

1. Name the New List
2. Select the Project for the New List
3. Check any Custom Participant Definitions that should be inherited from the Master List
4. Click Save and OK

 

 

View Participants in the Enterprise Manager

Clicking on the View Participants Icon in the Participants list will display all participants.

 

 

All steps to Edit and View Participants are the same in the Enterprise Manger as in a Discovery Study.

Edit Participant – Update the information for a single participant

View Participant – Displays the Participant Summary View