Participant lists contain key information, or properties, on survey or study participants. This data can be used, or piped, into surveys, studies, and emails to personalize communications and survey questions.
Within DatStat there are two types of Participant Lists: Master and Derived.
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.
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.
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.
When creating a Derived List from a Master List with Relations, Users are able to select the Relations to make available in the Study.
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:
DATSTAT_SITE – Unless Set Site from Master List, is checked when creating a Derived Participant List
DATSTAT_ALTPID (but it does default to the MASTER list’s value if none is specified)
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:
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:
Users may edit the following fields of a Standard Participant Definition:
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.
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:
Data Type* – Defines the way the data is stored
Possible Data Types:
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.
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.
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
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:
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:
.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.
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.
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.
When a participant list has custom properties, users have two options for creation of those properties:
NOTE: These Properties can now be inherited by 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:
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.
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.
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.
NOTE: The Definition MUST have a Display Type = Drop-Down List
NOTE: The Definition MUST have a Display Type = Drop-Down List
In the Parent Column select the Parent Column created above
NOTE: Each code must be unique even between values in the drop-down
NOTE: The Definition MUST have a Display Type = Drop-Down List
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.
To manually add a new participant to a Participant List:
NOTE: Make sure to select the appropriate Study Arm for the participant if this participant should be enrolled in a Study.
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:
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.
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.
Optional – If Creating a New Participant List
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