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.
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, Withings, 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.
Alert Message: Messaging encounter that is sent to a participant based on their notification preference and is visible on the participant dashboard.
Backend: This refers to the Admin site, WayToHealth internal API, and any software system that is not participant facing.
Commit number: A link to the code revision in our code versioning tools, e.g. r8849.
Completed: A status for an encounter in which the participant or study staff fulfill the requirements of the encounter (i.e. sync Fitbit, fill out a survey, etc.) and it closes out immediately or at the end of the encounter window.
Compliant: A status for an encounter that is both complete and meets specific parameters built in feedback, 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.
Device Upload: an encounter type that looks for participant data from a specified device source and runs feedback based on a participant's completion or compliance, often linked to a target, on the encounter.
Disable Feedback: Turns off automatically generated feedback to a participant or partner on an individual or study level. Feedback will be marked as applied even though none of it is actually evaluated. When feedback is reenabled, the participant will not receive feedback. See Pause Feedback.
Encounter: represents a specific action a participant or the system needs to complete, like a lottery, or taking a medication.
Encounter Window: the duration of time in which an encounter must be completed.
Enrollment Block: A time-bound set of encounters within enrollment.
Enrollment Step: a step a participant must compete during the enrollment process.
Feedback: Configurable actions that the system takes in response to an encounter
Feedback Consequence: an action the system takes after evaluating the specified criteria, such as sending a message or paying a participant.
Feedback Criteria: the conditions evaluated when applying feedback.
Frontend: Interactive participant-facing website comprised of the welcome screen, enrollment and participant dashboard
Filter Encounters: a page in the admin site where admin user can search for and edit encounters (e.g. reapplying feedback)
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 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 that is currently being phased in to replace Trac.
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.
Lottery: a type of encounter that represents a lottery winning for participants.
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.
Office Visit: A type of encounter that enables a survey that is only visible to and able to be manually completed by study staff, which is unlike a survey encounter that a participant can view and complete.
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 Feedback: Temporarily turns off automatically generated feedback to a participant or partner on an individual or study level. Feedback, including messaging and lotteries, 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, encounters, 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.
Round Up: An encounter that looks at previous encounters for completion and/or compliance and then applies feedback to the participant
Task: A scheduled process that runs behind the scenes, fetching data, applying feedback, generating reports, and so on. See Background tasks 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 feedback 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.
Trac: An issue, bug, and development tracking system that allows study staff and program developers to collaborate via tickets. Trac is currently being phased out and will be replaced by JIRA.
Transaction: represents a payment to a participant generated by feedback that must be approved by the study staff.
Schedule: Composition of encounters that is unique for each study arm.
Skipped: An encounter status for when an encounter window has ended, but the encounter 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.
Survey: A series of questions a participant must answer, provided via integration with Qualtrics. Surveys can be administered either during enrollment or the intervention period, and can be completed by the participant himself or on the backend by study staff.
Survey Lookback: An encounter type that evaluates a participant's response to an previously administered survey and sends feedback based on the various response choices. This allows you to send tailored feedback only to the participants for which the information is relevant.
Sync from production: To copy a version of the data from production, with all identifiers removed, to either staging or a developer's computer.
Update APIs: a background task that retrieves data from 3rd party APIs.
Ummon: the scheduler tool for WayToHeath background tasks
Variable: In an encounter message, a variable auto-populates unique information about a specific participant or encounter.