Before we can get into the intricacies of participant ages or where (and how) date of birth may play an important role, we need to address the settings that determine whether this information is collected in the first place.

Luckily, this is easy. There are only two settings relevant to participant age, they’re right next to one another, and it’s pretty clear that one is more important than the other. The more important one is the Participant Date of Birth (D.O.B.) Requirement setting:

Here we can see our first hint of some possible nuances to come. This isn’t an all-or-nothing, yes/no setting. It can be disabled, but there isn’t any corresponding “enabled” setting. Rather, you can make date of birth an optional input or make it required. One of the takeaways we hope you’ll get from the different topics covered here is that there may be a lot riding on this choice.

To spoil the surprise somewhat, we can tell you right now the main difference between “optional” and “mandatory.” Ok, clearly the main difference is in the name, and just as obviously this means one is mandatory while the other is…you get the idea. But beyond the obvious lies some subtlety, and much of the time this revolves around how Sona evaluates age when participants choose not to provide their D.O.B.

If participant age is “optional”, then any participant who didn’t provide their D.O.B. will fail to meet any age restriction or requirement, which most often involves studies.

There are, of course, other considerations and nuances at play here. In fact, just such a consideration arises when we consider the other age-related setting (which we will now do).

If you look at the image immediately above, you’ll see that this setting “only applies if participants are allowed to create accounts and date of birth is mandatory.” The former requirement (unlike the mandatory D.O.B.) may seem rather strange here because it has nothing to do with age.

While that’s true, it has a lot to do with the reason for this setting, which prevent participants below a certain age from creating their own accounts. It does NOT prevent the administrator from creating accounts or even batch importing an entire group of participants who are below the minimum age.

What it does do is check whether a participant’s D.O.B. makes them old enough to create an account. In order to do this, then participants must be able to enter their D.O.B. when creating an account:

This is why the Participant Age Limit setting requires that Participant Account Self-Creation be turned on. If participants can’t create their own accounts, they won’t see this page and this setting wouldn’t do anything. If participants can create their own accounts, though, this is where they input their D.O.B. If they don’t, they’ll get an error message when they try to complete the process:

This would normally be the point where we would get into the why’s and how’s of the setting itself. In this case, most of this is pretty self-explanatory: This setting allows you to enforce an age limit for your entire site.

An obvious motivation would be when institutional policies require that all participants be at least X years old. Along the same lines, your institution may not have a minimum age requirement, but there are typically regulations that require e.g. special permissions and review board scrutiny when the participants are considered minors.

Now that we’ve seen where the age-related settings are and how they work, we can turn to the most common application: the Age Restriction feature for studies. First, we’ll look at how to set age restrictions for studies, then how the system applies these restrictions. This will naturally lead to the difference between online studies, where age is calculated based on the signup date, and lab studies, where age is calculated using timeslot dates.

Finally, we’ll end with an example illustrating how Sona calculates participant ages (and determines eligibility) using timeslots.

Adding Age Restrictions to Studies

This is a study that already has an age restriction. The next obvious step is to learn how to configure a study that didn’t already have an age restriction.

To set such a restriction, click on the Study Menu and select Change Study Information from the dropdown list. This brings you to the study’s information and settings page. Scroll down to the Age Restriction section of this page (shown below), and select the desired age range:

The image above shows an upper age limit of 99. As you may have guessed, this isn’t designed to prevent centenarians from participating. Choosing an upper (or lower) limit far above (or below) any expected participant age is the practical equivalent of having no upper (or lower) age limit at all. If you wanted an upper age limit for a study, but no lower limit, this is even easier—just enter “0”.

Signup Date or Timeslot Date? Age Restriction differences between lab & online studies

So far, so clear. Next, we’d like to know how the system enforces these age limits. For the most part, this is straightforward. If the participant’s age isn’t in the desired range when they’re looking to sign up, they can’t participate, right?

Well, yes and no. And, also, “sort of.” For online studies, that is indeed how it works. When the participant signs up for an online study, the system uses that day (the signup date) to calculate the participant’s age, and then determines whether or not they meet the age requirement.

Lab studies work somewhat differently. Instead of calculating age from the signup date, the system determines what the participant’s age will be for each available timeslot. This is clearly different from the process for online studies, but just as clearly for a good reason.

When a participant signs up for an online study, they can click on the link and do the study right then, or in an hour, or at any time before the deadline. To ensure that the participant’s age falls in the required range, the system must use the signup date.

For lab studies, participants select timeslots. The timeslots are for specific dates, usually spread out over several days or more. These different dates can mean the difference between a participant who is old enough or young enough vs. one who is ineligible.

Birthdays and Timeslots: Example with Two Participants

To get a better picture (awful pun semi-intended) of what this looks like, let’s consider the following scenario: A study with an age restriction, a participant who meets this restriction already, and finally our star participant—Justin Time—who will be old enough to qualify for this study soon.

First, here’s what the already eligible participant (Henry Liddell) sees when he looks at the calendar view for the timeslot desired:

• Henry Liddell (eligible participant):

  
  

As you can see, there’s plenty of timeslots available. If you don’t see anything special here, don’t worry—you aren’t supposed to. This is just what an eligible participant would see if they were looking at timeslots for a study.

What about Justin Time, our participant who will be turning 18 (the lower limit on this study) during the month shown? Justin isn’t old enough to participate “now”, but will be old enough for at least some timeslots, so he can see the study listed. He won’t, however, see all the timeslots:

• Justin Time (soon-to-be eligible participant):

  
  

This is the same study Henry Liddell looked at and for the same month. For Justin Time, however, most of the timeslots that Henry saw don’t appear. This is because Justin Time can’t see timeslots that occur before his upcoming birthday (the one that makes him old enough to participate).

Situations like this are less rare than you might imagine. Many students start college at seventeen. Many universities also offer or require research participation credits for the very introductory courses that students may enroll in during their first semester. In prehistoric times, when P.I.’s sent research assistants to introductory lectures so they could pass out flyers, this caused problems. Sometimes 17-year-old students would show up full up hope and flyer in hand, only to find they didn’t qualify. The worst part? They may have qualified in a week or two!

These sorts of “Fall failures” are now past problems with Sona. Students who start college younger but who will be turning eighteen in time to participate can do so easily. Sona keeps track of age requirements for them, only showing them the studies they’ll be eligible for. Better yet, it shows them only the timeslots they’ll be eligible for, so that researchers don’t hope that participants will just happen to see the right flyer on just the right day!

Wrapping up the basics

This about covers our introduction to the basics. Before we move on, though, we want to call attention to an important distinction between the Age Restriction feature for studies and the Participant Age Limit setting. The latter requires that the Participant D.O.B. Requirement be set to “mandatory”, while the former (Age Restriction for studies) doesn’t.

This means that researchers can set age limits for studies even when participants aren’t required to provide their dates of birth. The curious reader may naturally wonder what, exactly, happens when 1) a study has age restrictions and 2) a participant who hasn’t provided their date of birth checks available studies. Will they see the study? Can they sign up for it?

We could answer such questions here, but then we’d have to address almost the ones again elsewhere. Instead, this gives us a great place to end with the basics and begin the more advanced topics. So, without further ado…

We finished our discussion of the most frequently used participant D.O.B./age application (Age Restriction for studies) with an unanswered question. If the Participant D.O.B. Requirement is set to “optional”, what happens for participants who opted not to provide their D.O.B.’s ?

We could answer this question by continuing to look at how the Age Restriction feature for studies works. Instead, we’ll take this opportunity to introduce another application of the Participant D.O.B. Requirement: the “minimum age” requirement for the Prescreen. Don’t worry, though. This will also address the same issue for studies.

The Prescreen’s Minimum Age Requirement

To make sure everybody is on the same page, let’s start with where the prescreen’s minimum age feature is. You can set or change this feature by selecting “Prescreen Set Up” from the Set Up dropdown menu and then clicking the “Edit General Information” button. Next, scroll down until you get to the section “What is the minimum age to take the prescreen?” :

Like the Age Restriction feature for studies, the prescreen “minimum age” works for both the “optional” and “mandatory” Participant D.O.B. Requirement settings. Both also work similarly. The biggest difference is simply that studies can have both lower and upper age limits, while the prescreen allows you to set a minimum. In either case, though, the system needs to have a participant’s D.O.B. in order to calculate age, which still leaves us with the question “What happens if the system doesn’t have a participant’s birth date?”

Handling Age without a Birth Date

Question: How old is someone who was never born?
Answer: Does not compute.

If the system can’t calculate a participant’s age, then it assumes the participant doesn’t meet any age criteria. For all intents and purposes, it is as if a participant whose D.O.B. is not in the system has an “exclusionary” age (an age that will always fail to meet any age requirement, and therefore excludes them).

This means a large number of your participants may be excluded from studies because they did not provide their information, not because they don’t meet the age requirements. Whether or not this is a problem depends upon your institution’s policies, practices, and participant pool. For example, if researchers seldom use the Age Restriction feature when conducting studies, then requiring all participants to give their date of birth may be unnecessary.

On the other hand, you might want a blanket age restriction to e.g., prevent minors from creating their own accounts. The most practical solution in this case may be to set Participant D.O.B. Requirement to “mandatory”, and create accounts for any special cases (e.g., younger students who are still minors, special non-student groups with minors or consisting of minors, etc.).

We leave the choice up to you. We don’t just want to provide you with options, though. We want you to understand the options so that you can configure your system to best meet you needs!

Exceptions may not prove the rule, but most of the time rules do come with exceptions. This is true of research, it is true of university policies, it is true of coursework and we’d argue it’s true in general. At the very least, it’s true often enough that we’ve made it possible for administrators to override many rules when exceptions must be made.

The Participant Age Limit setting, for example, is an easy way to impose a rule with the intent for there to be exceptions. An institution may conduct research with minors, yet still require that minors be treated as such (e.g., by collecting consent forms signed by the participant’s parent(s) or guardian(s) first). If the “minors” in this case are likely to be adults soon, then preventing them from creating their own accounts via the Participant Age Limit may be the ideal solution. If exceptions need to be made, they can be. Administrators can create these accounts individually or use the import wizard.

Overriding Study Age Restrictions for Eligible Participants

Often, however, age-related eligibility criteria or restrictions are specific to certain studies. If your site doesn’t require participants to provide D.O.B information, then any participant who chose not to give their birth date won’t be eligible for these studies, whether they truly are eligible or not.

To better understand what happens in such cases, consider a participant who is old enough to participate in a study, but who didn’t provide their D.O.B. when creating their account. As we just learned in the previous section, this means that the system will consider them ineligible for any study with an age restriction. They won’t be able to sign up on their own. The administrator can fix this problem by manually signing up the participant for an available timeslot of their choice (researchers can also manually add participants to timeslots, but for the sake of this example we’ll imagine that the participant contacted their site’s Sona administrator here).

Overriding study restrictions or eligibility requirements doesn’t happen very frequently, but it happens enough that administrators and researchers can do this if necessary. In the example we just examined, the participant actually was eligible for the study. What if that weren’t true, though?

This is a good question, and brings us to some potential pitfalls to be aware of.

Override Safeguards at the System-level

When it comes to the Participant Age Limit setting, the sort of pitfalls we refer to involve participant accounts. They could be participant accounts that the administrator creates without including D.O.B. information, perhaps overriding a mandatory requirement. Or it could be that the administrator switches from “optional” to “mandatory” when there are active accounts without D.O.B. information. Cases like these all involve a participant account that has no D.O.B. in the system despite the fact that this information is (at least now) required.

Sona, as usual, has built-in protections here. Whenever the Participant D.O.B. Requirement is on “mandatory” (even if it was only recently switched from optional), the system checks each participant when they log in for the requisite D.O.B. information. If the system finds no birth date for the participant, they will be taken to a screen like this:

In other words, so long as the system has a mandatory age requirement, participants will have to provide their dates of birth in order to participate. This is true even if they are already signed up or were added by administrators. That takes care of the system-wide override, but it doesn’t address what happens in other cases, such as when participants are added to studies.

Override Safeguards for Studies

Let’s go back to the participant we considered earlier who didn’t provide their D.O.B. when they created their account, and now wants to sign up for a study with an age restriction. An administrator can add them to one of the study’s available timeslot. In the scenario we considered previously, the participant actually met the age requirement, but the system was unable to determine that. Let’s look at a similar scenario, but with an important change.

The twist will be that the participant does not meet the study’s age requirement this time. Perhaps they heard about the study elsewhere, went to look for it without success, and then reached out to their Sona site’s administrator (the only contact information available to them). The participant reports that “something” is wrong, and asks that the administrator add them to an available timeslot.

We already know that the administrator can perform this action. In the first example, they had good reason to do so. Now they don’t. Luckily, in both cases, the system would warn them:

All the administrator would have to do now is ensure that the participant did in fact meet the age requirements. If not, then they would cancel the signup. It’s worth pointing out again that researchers can also manually add participants to study timeslots and, while this will also override the age restrictions for the study, they will see the same warning message displayed above for studies with age requirements that the participant doesn’t meet.

The lesson here is to be aware of when age restrictions or requirements may be at play and how to check if they are before performing an action that could override them. Yes, there are safeguards in place just in case, but they don’t necessarily prevent unnecessarily wasted time and effort!

We’ve discussed a lot of age related topics, and more than once referenced the system using D.O.B. to calculate participant ages, but we haven’t really talked about what this means. That is, if a participant is eighteen years, three months, and two days old, what is that in decimal notation?

The positive integer value of an age (the whole number part, without the decimal) is exactly what you would think. It represents years. With the exception of age maximums (we’ll get later in this section), this is intuitive.

What may not be so intuitive is the decimal part of age values. After all, a participant who is eighteen years, three months, two days old isn’t “18.00” years old. But what should come after the decimal point, and how is it calculated? It can be confusing, at least at first, to mentally “translate” a twelve month or 52 week year into a base ten/decimal system.

The system first checks to see if the participant has had a birthday this calendar year or not, and then counts the number of days since the birthday. If the participant’s last birthday was the previous calendar year, then the system counts from last year’s birthday. If the participant’s last birthday happened during the current year, then the system starts counting from this year’s birthday instead. These “partial year” age values (number of days since birthday) are then divided by the number of days in the year (either last year, if that’s when the count started, or this year, if the participant’s last birthday was during the current year). Finally, the result is rounded to the nearest two decimals.

If that seemed like a lot of details you’d rather not have to breakdown, and you’d prefer to skip the example scenario, we can still provide a simpler, more concise summary to help get the gist of the matter:

• The system calculates the decimal points by adding up the number of days X the participant has aged since their last birthday, and then divides this number of days X by the total of days in a year (usually, this means X/365).

This does miss out on some nuances, such as what happens in leap years or which year the system counts from, but if all you want is an idea of how it works, then that one-liner sums it up!

Before we end this section, we mentioned an “exception” to the otherwise completely intuitive whole number component of participant ages. We promised to cover that later, and we’ll finish this section by doing so!

Again, as long as you are aware of the nuance, it’s quite simple. If you want X to be the maximum age, use X.99 to include all X-year-olds. Let’s use specifics to make this clearer.

Suppose a researcher wants the maximum age for a study to be twenty-two. They may think this means putting “22” into the maximum age value in their study’s Age Restriction section. For the system, though, “22” is really “22.00”. Admittedly, that’s hardly shocking, but for age maximums this would disqualify anyone who is older than 22 years and 3 days.

It’s common to think a person is twenty-two until they are twenty-three. But the system is using 22.00 as a cutoff, while the researcher is thinking of a range that would include 22.01 (it wouldn’t). If a researcher wants to ensure that all twenty-two-year-olds are eligible for their study (and exclude anybody twenty-three or older), they should put “22.99” as the maximum age.

For researchers, most of the time age ends up translated into one or more average values (e.g., mean age for participants in a study iteration, round, component, etc., or perhaps mean ages by categories such as gender within a study). This is one way researchers use the Download Participant List (the subject of this section).

The problem is that participant ages are calculated using date of birth. An age can easily be de-identified for raw data storage, but actual birthdates are inherently “identifiable”. Administrators, who can also view the Download Participant List, may see the potential for a problem here, particularly if researchers want to simply download the participant list and use these data to create their raw but de-identified datasets. After all, as administrators can readily verify, the Download Participant List results in a table that contains dates of birth. Does this mean researchers have to manually go in and change D.O.B.s to ages?

No, because researchers won’t see what administrators do. This is one of those times where it can benefit administrators to add a researcher role to their account in order to see what a researcher would see. Often, there’s not much difference. Here, there is:

If an administrator generates an onscreen or downloadable table using the Download Participant List (and the Participant D.O.B. Requirement settings isn’t disabled), then there is indeed a column with birthdates. That’s not what researchers see:

The researcher version, the one intended for calculating values that end up in the research and for constructing the raw datasets, already takes care of the privacy issues by using ages rather than participant D.O.B.

This is also a good time to look back at the basics. Researchers see ages, but how are these calculated when a study takes place over a long period of time? As we already learned, for online studies the age is computed using the D.O.B. and the signup date. For in-person/lab studies, it’s the date of the timeslot rather than the date the participant signed up for the study.

Participant ages can also be used to determine email recipients. Select Mass Email and Announcements from the Tasks dropdown menu. This will bring you to the Create User Messages page. Click on the Mass Email Notification button. Finally, scroll down the Mass Email Notification page until you pass the study exclusions section. You should see something like this:

If you see a similarity between age restrictions for mass emails/notifications and those for studies, that’s no coincidence. Age Restrictions here don’t just look like those for studies, they function in the same way. The parenthetical text beneath “Age Restrictions” that tells you this only applies to emails for participants helps ensure this similarity. Only participants can, well, “participate” in studies. Emails can be sent to all user account types. The Age Restriction feature, on the other hand, applies only to participants.

We previously mentioned how researchers see only ages when they look at a study’s Download Participant List table. We also remarked briefly on the importance of individual ages for raw data in research (where it should be de-identified) and aggregated (often averaged) ages that appear as sample characteristics in the literature. Interestingly, there is one feature in Sona that uses the Participant D.O.B. Requirement setting, relies on aggregated ages, and is for administrators rather than researchers. This is the Course Summary Report.

Although it may come as something of a surprise, the Course Summary Report has two interesting and relevant properties:

1. If enabled (mandatory or optional), it uses the Participant D.O.B. Requirement setting.
2. It contains no participant ages

If you haven’t spent much time looking at this report (and even if you have) this may come as a surprise. It certainly seems paradoxical. A brief glance, though, makes clear how the report uses participant D.O.B.’s and yet doesn’t show participant ages:

The report requires participant ages in order to populate the “Average Age” column, but the report contains only averages. We probably wouldn’t even be mentioning it in this blog (however useful the report itself is) were it not for one, small detail: the average average.

If you scroll down to the last row in this report, you’ll see that it provides totals. If your report includes the age column, then naturally there’s a total here as well:

For every other cell in the Average Age column, the average is computed how you’d expect it to be. The participant ages are added together and the result is divided by the total count of participants. If you have the Participant D.O.B. Requirement on “optional”, then participants who haven’t provided their ages aren’t included in the average.

The last row of the Course Summary Report is different, both computationally and conceptually. It does not represent an average of participant ages. Instead, it’s the average of the course age averages. This may sound complicated, but it’s much simpler. The number of cells (course age averages) from this column are added together and divided by the number of courses.

This has at least two clear benefits. First, a total average of all participant ages here would likely be misleading (some participants may be in more than one course, the courses have different sizes, a course could have more students but fewer participants, etc.). The overall average is much clearer. Second, you can read off the Average Age cell values yourself to verify the total.

The bottom line of the bottom row is that it actually doesn’t represent an average of ages, but an average of averages.