Glossary

This is the glossary of Way to Health concepts. 

Access Group: A designation in Manage Study that allows study staff to assign providers to a group of participants and limits their access to other groups of participants.  Once created, participants can be assigned to 1+ access groups. Typically, access groups are used for multi-site studies or for clinicians who are managing a caseload of their patients. 

'Add 'Logic (formerly known as Round Up):  An event that looks at previous events for completion and/or compliance, survey responses, or gamification scenario and takes action on the defined criteria, including adjusting point balances and levels, crediting a participant, sending out messaging to the participant, support partner, or project staff. 

'Administer a Qualtrics Survey': An event type that pulls a series of questions from an integrated Qualtrics survey that a participant must answer.  Surveys can be administered either during enrollment or the intervention period, and can be completed by the participant himself or on the backend by project staff. Surveys that are only visible to study staff cannot be viewed or completed by participants. 

Almanack: A web application where WayToHealth financial data is aggregated and reconciled. https://almanack.waytohealth.upenn.edu/login

Aggregator:  Source that pulls data from two (or more) devices of the same type  Aggregator Setup

Averager: A site-specific tool found under Device setup that allows users to define how the platform will take the average of a particular data point over a period of time. Example: The user wants to take the average step count count for 1 week, but needs at least 4 days of data that is greater than 1,000 steps.

API: A way for one software program to talk to another. In the case of WayToHealth this can refer the WayToHealth internal API (how the front end talks to the backend) or a 3rd party data source (how Way to Health gets data from Fitbit, Nokia, etc.)

Alert: An automatically generated message sent to the study team that can be set up to monitor for rapid or extreme changes in a participant's data that may be of clinical significance or a sign of an adverse event. 

Backend: This refers to the Admin site, WayToHealth internal API, and any software system that is not participant facing.

'Collect Data': an event type that looks for participant data from a specified device source and runs logic based on a participant's completion or compliance, often linked to a target, on the event.  

Commit number: A link to the code revision in our code versioning tools, e.g. r8849.

Completed: A status for an event in which the participant or study staff fulfill the requirements of the event (i.e. sync Fitbit, fill out a survey, etc.) and it closes out immediately or at the end of the event window. 

Compliant: A status for an event that is both complete and meets specific parameters built in logic, like a goal or target. 

Confluence: Team collaboration software that serves as a resource guide for study staff and developers for building and managing Way to Health.  

Connector: refers to code that connects with a specific 3rd party device.

Cohort: represents a group of participants within a single arm. Can be used for team functionality.

Dashboard: This term is used in two ways: 1) Interactive component of the frontend site where study participants can log on and view study instructions, payments, game features, resources, contact study staff, etc. 2) For some studies (especially CMMI), the Manage Participants view where study staff can view adherence data for multiple participants.

Dashboard card: a distinct section of the participant dashboard that serves one specific purpose.

Device: a source of participant data that can come from one of two origins, (1) a tangible device, such as a pedometer or wireless scale, or (2) a non-Qualtrics survey, such as pre-commitment, goal selection, or Twilio bi-directional.

Disable Logic:  Turns off automatically generated logic defined on an event to an individual participant or at the study level.  Logic will be marked as applied even though none of it is actually evaluated. When logic is reenabled, the participant will not receive messaging, updates to point balances/levels, lottery evaluations, etc. See Pause Logic.

Event (formerly known as an 'Encounter'): represents a specific action a participant or the system needs to complete, like a lottery, or taking a medication.

Event Window: the duration of time in which an event (formerly known as an 'encounter') must be completed.

Enrollment Block: A time-bound set of events within enrollment.

Enrollment Step: a step a participant must compete during the enrollment process.

Frontend: Interactive participant-facing website comprised of the welcome screen, enrollment and participant dashboard

Filter Events: a page in the admin site where admin user can search for and edit event (formerly known as an 'encounter')s (e.g. reapplying logic)

Form Submission: how participant data, such as surveys and device data, are represented by the backend system.

Hard-coded: anything that is fixed to a specific value directly in the system's code base, such that only a developer can change it.

Incident:  There are 2 types of incidents. They can be automatically generated by WTH for issues with a device event (formerly known as an 'encounter') or a participant, or added manually by study staff to document relevant information on a particular participant.

Iteration/sprint: The 2-week time period that the development team allots to complete outstanding tickets and Way to Health enhancements.  

IVR (Interactive Voice Response): Participant communication preference that sends alerts via automated phone call

JIRA: An issue and project management tracking system.  The WTH team uses JIRA collaborate internally for operational tasks, platform feature enhancements and development work, as well as with users to troubleshoot issues, bug, and general platform questions. 

Jenkins: The system responsible for running automated tests and deploying studies to servers.

Local environment: A version of WTH running on a developer's computer. Code can be changed here quickly, but it needs to be saved ("committed") to our code repository and deployed to a server before it's visible to any users.

Logic Action: an action the system takes after evaluating the specified criteria, such as sending a message or paying a participant.

Logic Criteria: the conditions evaluated when applying logic.

Manual Transaction: represents a manually entered credit to a participant through their profile that must be approved by a project manager.   

Notification: Any message sent from Way to Health. Could be manually or automatically generated, and sent to a participant or RC.

Participant: Person who is enrolling or is enrolled in a study. Sometimes called a "Study User"

Participant Status:  Indicates a participant’s stage of enrollment or progress in the study. See Participant Statuses for more info

Participant Partner: A user who is linked to a study participant through a separate 'Partner' study. Participant partners can log into their own Way to Health account , interact with the site (i.e. complete surveys), and receive notifications about a study participant, typically non-adherence alerts or a participant's progress, in order to provide additional support. 

Pause Logic: Temporarily turns off automatically generated logic defined on an event for an individual participant or study level.  Logic, including messaging, lotteries, point/level changes, will be sent to the participant or partner when resumed.

Payment: a check made out to a participant processed by Wells Fargo and created from an approved transaction.

Plugin: a module of code that accomplishes a specific function or set of functions, like interacting with a device API, or performing randomization. Most core Way to Health functionality is built in the "Way to Health plugin", so we'll sometimes refer to "The Plugin" meaning platform-wide (as opposed to study-specific) functionality.

PMACS: Penn Medicine Academic Computing Services - the IT department of the med school, who manages the WTH servers.

Prerequisite: a step that must be completed in the enrollment process for the participant to move ahead to the next enrollment step.

Production:  Secure, live server of the study website.  

Provider: A study staff permission that restricts a user's access to only a group of participants assigned to an Access Group to which they have permission to see.  A provider can view participant information, events, transactions, and data only for those in their assigned Access Group. A provider cannot view Manage Study and therefore typically only supports study management. 

RC (Research Coordinator): Member of the study team who aids in study enrollment, maintains study platform, and acts as a point of contact for study participants.

'Run the Lottery': a type of event that represents a lottery winning for participants.

'Send a Message':  An event type that sends a message to a participant based on the designated notification preference and is visible on the participant dashboard. This event type should be used to push alerts or notifications to participants, but cannot apply logic or receive a response from a participant. See 'Send a Conditional Message'.

'Send a Conditional Message':  An event type that sends a message to a participant based on defined logic criteria of a previous event. This messaging event can evaluate a previous event's completion/compliance, point balance/level, previous survey response, etc. and send the participant tailored feedback based on the logic.  

Silence Messages: A logic and notification preference set on an individual participant's profile.  Enabling this setting will run all of the logic built on scheduled events (point balance deductions, lotteries, etc.), but the participant will not receive any messaging from these events.  Participants can still receive batch notifications sent from the Manage Participants page. 

Schedule:  Composition of events that is unique for each study arm.  

Skipped: An event status for when an event window has ended, but the event was not completed. 

Staging: The server environment that replicates the production environment as closely as possible, often used for testing.

Shadow:  Separate study created on production that can be modified to be tested on a shorter time frame.  Shadow is often used during the testing phase, pre-launch of a study.   

Source: a device or survey

Study Root: In a study's URL such as my.waytohealth.upenn.edu/framingham/shadow, the portion immediately after the first slash (in this case, "framingham")

Study Slug: In a study's URL such as my.waytohealth.upenn.edu/framingham/shadow, the portion after the second slash (in this case, "shadow")

Study Default Slug: The study whose page should load if you leave out the study slug. In the above example, if you were to visit my.waytohealth.upenn.edu/framingham, the main ("framingham") study would load.

Support lead: The developer assigned (for a specific time period such a week or two) as the main technical point person for new support issues.

Support Partner: A user signed up to receive notifications about a study participant, typically non-adherence alerts or a participant's progress, in order to provide additional support or serve as a second point of contact for the participant.  A support partner cannot log in to Way to Health or interact with the platform, instead see Participant Partner.

Sync from production: To copy a version of the data from production, with all identifiers removed, to either staging or a developer's computer.

Task: A scheduled process that runs behind the scenes, fetching data, applying event logic, generating reports, and so on. See /wiki/spaces/technical/pages/21496339 for more info.

Target:  Form of goal setting for participants that can be automatically generated at different times during the study. The targets can be evaluated against in logic criteria or simply used to encourage the participant.

Ticket/Issue:  A bilateral tracking system that allows study staff and developers to interact.  The study staff outlines a description of functionality requests and issues/bugs, and the developers record changes and deploys.

Transaction: represents a payment to a participant generated by logic that must be approved by the study staff.   

Update APIs: a background task that retrieves data from 3rd party APIs.

Ummon: the scheduler tool for WayToHeath background tasks

Variable: In an event message, a variable auto-populates unique information about a specific participant or event.