ePro Configuration
      Back to home
      1. Help Center
      2. Study Configuration and Form Building
      3. ePro Configuration

      Configuring Study For ePRO and eDiaries

      Setting up a Study to Collect Data From Participants at Defined Intervals, Frequencies, and Times of Day

      This article covers the setup and configuration of studies that need to collect data directly from Participants. This is generically referred to in TrialKit as ePRO but also includes the collection of diaries.

      Prerequisites:

      Table of Contents:

      Enable ePRO for Study

      Methods for deploying the forms:

      Participant Notifications

      Allowing Participants to Access Past Forms

      Giving Access to Historical Data

      Testing an ePRO Study

      Enable ePRO for Study

      Similar to other functions, the master control to enable ePRO must be turned on. This is done in  Study Configuration / Functionality.

      Many of the initial steps covered here may already be done within the study based on the template configuration but is good to run through each step to verify.

      In the Role Security tab, add a new role for the Participant (can be named anything), like below.  The subject must have a hierarchy value of zero (0) and a Role Type of 'Site'.  

      The new Participant role must also be given the following permissions:

      Additionally, give this new role view/edit access to the forms they will be completing.

      Setup the Registration Form to Collect the Participant's Email Address and Timezone

      The form that is serving as the study's registration form needs to collect the Participant's email address and timezone. To do this:

      Add an email address field onto the form and set the special type field property to "Subject Email".

      The patient's email address will NOT be included with other form data in the data exports or reports. It will be visible on the form for any users that are not blinded to it.

      Add a dropdown field to the form and set the special type property to "Timezone". Do not add any choices to the dropdown field. It will be populated automatically during data entry.

       

      Include an Email Conditional Action to notify the Participant of how to sign in

      When a Participant is registered in the study, while not required, it usually makes sense to have the system also send an email to the Participant notifying them that they have been added to the study and include any instructions on how to access TrialKit. A template/example is shown below, but can be configured any way as discussed in Email Notifications for Conditional Actions.

      Defining Which Forms Will be Completed by Participants

      Any forms that need to be accessible to the Participants should contain the 'ePRO' form property. 

      If the form is collected repeatedly as a diary (not within a scheduled visit), it should be tagged as a log form with a relation of 'Many'. A consent form or a daily diary are two examples of this.

      The Visit Date Field on ePRO Forms

      Visit Dates are defined on any subject-type form. ePRO forms are no different, but the system will do something different with this date during data entry. When a Participant opens the form to complete, this date will auto-fill with the user’s current date/time (based on their timezone preference). 

      For this reason, it's normally advised to make the visit date field a date+time and label it as "Date Entered" or something similar, since the system will be auto-populating it.

       

      Methods for Deploying Forms To Participants

      There are four methods of providing forms to study Participants and making them available for the specified duration of time. The combination of these methods will cover most requirements that studies have for making sure forms get completed at precise time points in a given Participant's study involvement.

      1. On a defined fixed interval (in weeks, days, or hours).
      2. On specific days and times of the week, up to hourly at the top of the hour.
      3. Based on an event triggered by the Participant - One of the ePRO forms conditionally triggers a schedule of follow ups for that event. Triggered forms can be deployed up to every 5 minutes.
      4. Forms collected within the visit schedule

      eDiary Configuration

      The Diary Configuration screen is where you can define which ePRO forms to deploy at a specified frequency. 

      Web Browser: 

      Open the Participant Diary Configuration screen.

      This will open a table of existing diaries and a button for adding new ones.

      Mobile App:

      ediary1menu

       

      To create an eDiary/ePRO form, add a new configuration and fill out the form. Here's an example of a diary form that the Participant needs to complete every morning at a specific time, starting at the Day 1 visit, and they have 1 day to complete it each time the form is deployed. After 90 days the diary will stop running (per subject based on their respective Day 1 visit date).

       

      To understand how diaries work and how their resulting schedules can be viewed, read this article: Diary Schedules

      Definition of Terms in the Diary Configuration

      • Starting Interval - When the diary as a whole will start running. The system needs a reference point for this and visit intervals are a great way to define that point.
      • Expiration in Days - The total overall duration in which the diary should run. 
      • Time Unit - The value set for the Frequency and Completion window will be based on the time unit set here. Example: "5" for the completion window will mean 5 days if the time unit is set to days.
      • Completion window - For each iteration of a form being deployed, how long should the Participant have to complete it before the next iteration comes due.
      • Forms to deploy - Check which form(s) apply to the diary deployment configuration. 
      • eDiary Type - The type of diary that's needed is described in the following parts of this article.
      • Frequency - How often the form should be deployed based on the time unit?  If the time unit is set to hours, a frequency of "3" would mean the form is getting deployed every 3 hours.
      • Maximum Forms - How many forms can the Participant enter as a maximum. This will determine if the diary should be turned off before the expiration days that were defined.
      • Do not send notifications - This prevents the system from sending notifications each time a form is deployed.

      At a Defined Interval

      Forms that need to be collected on a regular recurring interval. For example, every 1 day, every 7 days, or to make a form always available.

      Within the Diary Configuration screen, choose the Diary Type "Interval", and fill out the parameters of the diary. Read above on how to configure an eDiary.

      Always Available forms: If a form needs to be constantly available to the Participant, the frequency should be set to zero (0). This will make it so a form is always there. If the Participant saves one, another one will be available to complete. This will occur until the diary expires or the maximum number of forms has been reached.

      Notifications

      Each time a form is made available, a notification will be sent to the Participant.

      Exceptions:

      • The Do Not Send Notifications option is not checked
      • The diary is always available
      • In the example shown above, the Participant will be notified every 24 hours (1 day) after the low range of the Baseline visit interval date

      How Long the Form will be Available

      Each iteration of a form will be available until the defined completion window is reached or until the form is completed.

      The Diary will expire (stop running) based on:

      • The expiration period for the diary has been reached
      • The study exit form is completed for the Participant
      • The maximum number of forms has been met

       

      Specific Days and Times of Each Week

      Forms that need to be completed on specific days and times of the week. For example, every Monday and Friday at 7 am and 7 pm.

      Within the diary configuration screen, choose the 'Specific Time' type. Then tap on any day of the week that the form needs to be available. A window will open to also select the time(s) for that day.

      Include time in the visit field of the diary form.

      Avoid overlapping other diaries or time windows. See the following examples.

      Overlapping diary examples (to avoid):

      • If a diary is set to go out at 6 p.m. and expire after 8 hours, there is an overlap into the next day. If the diary is completed at 1 a.m., then the system thinks the diary is complete for that next day.
      • If the visit date defined on the diary form does not include time, the system will assume it was saved at midnight whenever the patient saves it, which may prevent it from not disappearing from the Participant’s list of forms due.

      Notifications

      Similar to Interval diaries, the Participant will receive a notification each time a form is deployed for delivery. The notification message is defined within the ePRO Notification settings.

       

      A Triggered Event Schedule

      A specific schedule of forms needs to start deploying at a conditional time point.

      For example, a drug diary is needed for a Participant to indicate when the drug is used. Based on that "event", follow-up form(s) needs to be filled out every 2 hours for the next 6 hours and then every 12 hours for 3 days.

      The most versatile way to set these up is through a conditional action on the form that should trigger the event (the 'Trigger form'). By using a conditional action, you can define exactly what is needed to trigger a preset schedule of intervals (the "Event Schedule" and form(s) that will be collected at those intervals within each event.

      Configuring an Event Schedule

      The Event Schedule option is available if the study is an ePRO study. 

      On a Web Browser, it is found within the Participant Diary Configuration screen:

      On the Mobile App, it is located under the study configuration menu:

      From the screen above tap the New Schedule button at the top to create a new schedule. Doing so will prompt for a schedule name and starting interval. The starting interval is the point at which the trigger condition can initiate the schedule. If a trigger condition is met for a given subject, but that subject's visit schedule is not yet at the starting point, the event schedule will not be triggered.

      Any number of event schedules can be created to deploy a different schedule of ePRO forms or wearable device activities based on pre-defined criteria (conditional actions). Use the dropdown at the top of the screen to toggle between the events that have been configured.

      To edit an event schedule name or starting interval, tap the first column header.

      To edit any of the intervals within the schedule, tap the Interval's column header. From here you can then define the interval name and parameters:

      • Time Unit - Unit of time for the value used in Time Post Event
      • Time Post Event - How long after the trigger event (visit date field on the trigger form) will the interval begin
      • Completion Time - The amount of time in minutes that the interval is available for the Participant to complete the form(s) in that interval

       

       

      Lastly, include/require any forms or wearables data that must be collected at each of the intervals. 

      Wearable device data can include the following for Apple Watch-supported studies:

      • Heart rate snapshot
      • ECG
      • 6-minute step test
      • Sleep analysis
      • HR Variability
      • Resting HR
      • Activity Rings
      • Blood oxygen
      • Blood Pressure

      How Long the Triggered Form Will be Available

      The form that gets triggered for a given event will be available for the duration specified within the event schedule, or until the event is terminated by terminate conditional action.

      As events occur and forms get completed by the Participant, those can be tracked within the Events Report.

      Important points:

      • The trigger form (the form where the event trigger CA resides) must be completed (all edit checks satisfied) to trigger an event. The condition must also be met. If the condition is not met, but the trigger form is completed, and event will display in the subject's casebook, but no event intervals will be deployed to the Participant. This is so a Clinician can track saved events - including ones that did not warrant triggered follow up forms to the Participant.
      • The trigger form will, by default, be always available to the Participant. If it only needs to become available at a certain point, it can be configured to be conditionally hidden.
      • However, Forms within event intervals cannot be conditionally hidden. This is by design because it allows for real-time delivery of time-sensitive forms and notifications. If the system enforced hiding, the notifications would not be able to process fast enough to ensure timely delivery.
      • Fields within event interval forms CAN be hidden. To hide fields within specific event intervals, write the CA on a field using the "Event Follow up" constant.

       

      Within a Scheduled Visit Window

      To collect forms within a scheduled visit, simply make the form part of a visit that has the required date/time window. 

      In the example below, a diary needs to be collected from the Participant during the same period of time that the 3-month follow-up visit occurs.

      The form will be available for Clinicians to view within the subject's casebook, assuming they have view rights to that form, but it will be entered by the Participant.

      The Participant will get access to the form at the low window date of the visit. 

      Important Notes:

      • Scheduled visits are primarily intended for site visits or Clinician-entered data. It is not advised to configure an entire ePRO study via the visit schedule, particularly if forms are due at specific times of day, or at specific hours. Instead, consider using the Event Schedules.
      • If any ePRO forms are collected in a "TBD" visit, the system will still deploy the forms to the Participant based on that default time range computation. To prevent that, use a hide conditional action on the ePRO form so it does not show until that dependency date exists.

      Notifications

      If the form is set to have notifications, a notification will be sent to the Participant at the low window date for the visit. This assumes the form is not set to have the notifications disabled.

      This notification is configured in the ePRO Notification Configuration screen.

      Notifications for scheduled visits have a limitation of running at the top of each hour and could be delayed past the top of the hour by the time the Participant receives it. If a visit is due at 9:08 a.m., the notifications will not run until 10:00 a.m. The participant may not receive it until 10:15 a.m.

      For this reason, do not use visit schedules to deploy hour-specific forms. Instead, use time-specific diaries or an event-triggered schedule.

      How long the form will be available

      The form will be available for the Participant to complete until the high end of the visit window, or until the form is completed. If the study exit form is completed for the Participant, then the visit window will not apply.

       

      Notifications To Participants

      Participants will receive notifications anytime a form becomes due, based on how the Visit schedule or eDiary is configured. Here are a couple of examples:

      • 6-month follow-up visit includes an ePRO form. The Participant will receive a notification on the low date of the visit window. The form will remain available for the duration of the visit window and may also receive reminder notifications depending on the Notification configuration.
      • The Interval diary goes out at a frequency of once per day for 10 days after the 3-month follow-up visit. Starting on the 3-month follow-up visit, the Participant will begin receiving daily notifications until the diary expires in 10 days or the maximum number of forms have been entered.

      If the Participant user role does not have view rights to a form that is being deployed, a notification will still be sent, but the form will not display in their list of forms due.


      There are various reasons notifications might not go out when a form becomes due:
      • Notifications are not configured in the ePRO Notifications screen.
      • Notifications have not been allowed in the eDiary settings - as detailed in the section above.
      • The form is collected in an hourly-based visit schedule. Visit schedule forms are limited to one notification per day. The first notification will go out based on the visit window, but if there is another visit in the following hours of the same day, a notification will not go out. Only the form will be due to be completed. For hourly notifications, use an eDiary rather than a visit schedule.
      • The ePRO form is configured in the form builder to not send notifications.
      • The visit window is not active or has already sent a notification for the current window.
      • The Participant has disabled notifications to their preferences.
      • The notification message contains HTML and cannot be sent via push notice or SMS.

       

      Allowing Participants to Access Past/Completed Forms

      Participants can optionally be given access to one or both of the following:

      • Past forms that have been entered, but are not yet locked by a review level. These are called "Completed Forms", and are made available to Participants via the Study Functionality Settings. Access to completed forms can be even further controlled from being edited. Read more here.
      • Forms collected within a visit schedule that were missed (visit window expired). These are called "Expired Forms", and are made available via the Study Functionality Settings.

      Participants then access those forms via their Menu Options.

      Controlling Which Completed Forms Can Be Edited

      If Participants have access to Past or completed forms, the study Manager can prevent Participants from editing either all of the forms, or only some of them. This is done by the following two controls:

      • Permission in subject record management to Allow Participants to Edit Existing Records - By default this is disabled and subjects will have access to completed forms, but not be able to edit any of them. If this is enabled, then the next control can be set to allow only certain forms.
      • Form property to Prevent Form Editing - Prevents Participants from editing any forms that are completed without errors. This is enforced anywhere that epro forms are accessible by the patient. The completed forms list will also indicate "read only" for any forms that do not have this property set.
         

      Giving Access to Historical Data

      Participants can optionally be allowed to view past data that auto-filter the Participant's data. This is useful for Participants to see all the data they have entered without going through past completed forms. For example, the Participant can view a history of how well they have felt since being part of the study.

      This is done via the Report Builder where a report can be targeted to the Participant's role.

       


      Testing An ePRO Study

      As a study gets configured with the Participant-facing forms needed, testing it out is an important step to verify the desired behavior. This can seem difficult since consenting may be involved and forms might only get deployed occasionally, such as a 1-month follow-up visit. It doesn't make sense to wait one month to see if the form becomes available to the test Participant. This section provides a step-by-step on how to efficiently test the consent and PRO portion of the study.

      1. Register a subject with an email address that is owned by the person performing the testing. An alias address usually makes the most sense here so there are not multiple inboxes to monitor as the testing is done. Most email platforms, like Google Workspace, provide a method of quickly creating alias addresses. In Gmail, this is done by adding "+sometext" in the prefix. For example name+studyA@gmail.com.

      To make the testing email addresses easy to track, use the study name and subject ID in the email. For example name+studyA_100002@gmail.com. Now when you get an email in your inbox, the email will show you the study and subject ID.

      Do NOT use fake email addresses as this will impact the study's rating with the email servers and their ability to send any type of email in the future.

      Each Tester only needs one or two test Participants for a given study. There is never a need to continually add more subjects to a test environment with several different email addresses involved. Doing this over time, especially on multiple studies will produce hundreds of 'junk' email addresses and cause potential issues down the road.

      If forms or behavior needs to be re-tested, there are tools for deleting records and revoking consent to 'refresh' a given test Participant for using it again in the same study. 

      2. Verify the Participant received some sort of email notice on how to access TrialKit (discussed in the section above).

      3. Sign in as a Participant on either the Mobile App or Web Browser.

      If using the mobile app, and if possible, it's most realistic to use a dedicated device where only the Participant will be signed in. If the app is used to sign in with multiple user accounts on a single device, it will only receive push notifications for the user who was most recently signed in.

      4. If consent is being enforced for the study, verify the consent form works as intended both in an incomplete state and a complete state.

      To retest consent on a Participant, it can be manually revoked so the system will require that Participant to consent again.

      5. Verify the correct form(s) are due for completion at the right time. This part can be tricky because it's not desirable to wait for forms to become due. The due periods can be manipulated by adjusting the dates for the subject, which drives the dependent forms. For example, if a daily diary is supposed to start one day after the registration date, the registration date for that subject can be adjusted to yesterday's date, so the system thinks it is now a day later.

      To retest any ePRO forms or deployment dates, do not create a whole new test subject. Instead, simply delete the ePRO forms that were already entered for the existing test subject. This can be done within the subject's casebook.

      6. Exit/Withdraw the subject from the study to verify the Participant no longer receives forms or notifications.