Choosing between responsive-design websites versus mobile apps for your mobile behavioral intervention: presenting four case studies
Both mobile apps and responsive-design websites (web apps) can be used to deliver mobile health (mHealth) interventions, but it can be difficult to discern which to use in research. The goal of this paper is to present four case studies from behavioral interventions that developed either a mobile app or a web app for research and present an information table to help researchers determine which mobile option would work best for them. Four behavioral intervention case studies (two developed a mobile app, and two developed a web app) presented include time, cost, and expertise. Considerations for adopting a mobile app or a web app—such as time, cost, access to programmers, data collection, security needs, and intervention components— are presented. Future studies will likely integrate both mobile app and web app modalities. The considerations presented here can help guide researchers on which platforms to choose prior to starting an mHealth intervention.
KeywordsmHealth Interventions Mobile apps Websites Study design Health behavior
The field of mobile health (mHealth) has been growing rapidly. Since the introduction of the personal digital assistant (PDA) handheld computer, researchers have leveraged mobile digital technologies to disseminate and scale up health-related research and deliver real-time interventions . Early mobile digital interventions utilized technology, such as PDAs, for self-monitoring  and modalities, such as text messaging  and podcasts via MP3 players , for content delivery. In 2007, Apple introduced the iPhone . This broadened the ability of researchers to deliver multi-component interventions that could still include remote contact methods, such as podcasting and text messaging, but also leverage access to the internet, social media, and mobile apps for intervention delivery. In addition, smartphones have allowed for some of the computer processing to occur on the device—as opposed to processing that is performed exclusively by an outside server—and syncing to external sensors and tracking devices, such as physical activity trackers.
Mobile apps are programs that can perform certain tasks or provide certain functions for a user . Health apps are one of the most frequently downloaded category of apps . Although researchers have used existing, commercially available mobile apps in interventions [5, 7, 8], many health-related mobile apps do not integrate known strategies that have been shown to promote effective behavior change [9, 10, 11]. Therefore, researchers have sought to develop mobile interfaces that are informed by evidence-based practices and health behavior theories [7, 12, 13].
Developing mobile technology can be expensive and time consuming. The average mobile app costs $270,000 to create and takes between 7 months and 1 year to develop, pilot test, and then launch , with added upkeep for app updating that must occur afterward. In addition, there are now two main mobile platforms that mandate different programming and publishing requirements: Apple and Android. Responsive-design websites (web apps) provide an alternative approach to platform-specific mobile apps in that they that are generally much less expensive to develop and are viewable on mobile devices. Responsive websites are designed specifically to have flexibility across both mobile and non-mobile platforms, allowing for ease of use (minimal scrolling or resizing) across multiple devices .The average responsive-design web app costs between $5640 and $29,900 to create  and typically takes 10 to 16 weeks to develop [17, 18]. Additional costs can include yearly hosting fees, domain registration, and stock photograph services . Web apps are device agnostic, meaning content can display on any device that uses an internet browser, including smartphones, tablets, laptops, and desktop computers . There are several factors that must be taken into consideration when deciding on using mobile apps or web apps in research, including time, cost, and technology purpose and functionality needs. Additional considerations are data security, interoperability, and safety regulations. Depending on the intervention, a variety of government rules and industry standards may apply. Concerns around how confidentiality, security, and privacy issues are handled via mHealth devices have increased . These concerns pertain to both participants in research studies as well as non-participants, who may have photographic or voice data inadvertently captured . Data privacy concerns are particularly heightened when location-based data is collected, as that has the potential to increase the ability of identifying where an individual lives . mHealth safety regulations have largely focused on mHealth applications that serve as medical devices or device accessories, which would necessitate Food and Drug Administration (FDA) regulation . mHealth interventions providing behavioral strategies to study participants would not fall under FDA regulation . Mobile and web apps must also adhere to federal regulations related to consumer privacy. The Federal Trade Commission (FTC) had issued guidance to mHealth developers specifically on best practices for protecting consumers . This includes an interactive tool to assist mHealth researchers and developers in determining applicable federal laws when creating both mobile and web apps . Health information technology privacy and security efforts have largely targeted those in healthcare, governmental agencies, patients, and technology vendors , leaving those in academia left to navigate the varied governmental rules and industry standards. The objective of this paper is to present four case studies from public health interventions that developed either a mobile app or a web app as part of the study. In addition, this paper will provide a table to help researchers determine which mobile option would work best for them in their particular circumstances. Cost estimates for the development of each mobile or web app are provided and only include the cost for programming and development by the company or individuals who produced the app and does not include cost for researchers’ time to inform the development.
Case study no. 1: The Motivating Families with Interactive Technology (mFIT) study (web app)
The mFIT study was a randomized clinical trial (RCT) of two family-based obesity prevention interventions with parent-child dyads (child 9–12 years old). In early 2015, 33 parent-child dyads were randomized to either a traditional family-based approach or a mobile-enhanced intervention, both of which focused on promoting physical activity and healthy eating.
Formative work to inform development
A content analysis of commercially available apps for pediatric obesity prevention and treatment was conducted by the research team , revealing deficiencies in availability. Next, a pilot study was conducted to gather feedback from three parent-child dyads about the features of commercially available apps and physical activity monitors (e.g., Fitbit), as well as their proprietary monitoring apps. Feedback and suggestions for improvement were collected via questionnaire and structured interviews from the three dyads. This information was used to inform paper prototypes of the mFIT web app that were later developed with input from the technology development team.
Mobile web components
Families in the intervention condition of the mFIT study used a web app for six main purposes: (1) log their daily steps and food servings (e.g., daily servings of vegetables); (2) view their progress toward study goals (e.g., steps taken per day); (3) set weekly behavioral goals and rewards for reaching these goals; (4) view the progress of their family member (e.g., child could see the progress of their parent for each goal); (5) send messages of encouragement and congratulations to their family member; and (6) view weekly study newsletters with motivating ideas, recipes, etc.
Researcher data needs
The mFIT research team required relatively simple back-end tools from the website, including reports of data completed, participants who had not set goals, etc. Additionally, the web app was programmed to “lock” participants out of certain features of the app until they completed assigned tasks, such as setting weekly goals and rewards.
Who designed the web app
A computer programmer who was on staff at a university-based information technology group designed all aspects of the web app. This group is housed in the Arnold School of Public Health at the University of South Carolina with a goal of providing technology-development services to researchers. A researcher and graduate student from the Department of Health Promotion, Education, and Behavior guided the design of the mFIT web app based on formative research (described above).
Decision to go with web app
The decision to go with a web app was driven largely by the cost and time to develop a mobile app, given that mFIT was conducted as part of a doctoral dissertation with limited funding. However, the use of a web app had other benefits to the study, including the ability to recruit participants with any type of mobile device, as long as participants had reliable internet access. This proved to be helpful with the specific research population, as children in the study had less mainstream mobile devices of their own, including iPods and Kindles, which were still able to run the study web app.
Total timeline and cost from start to finish
Initial meeting with technology group: July 2014; screenshots of app delivered from designers: September 2014; follow-up/prototype: October 2014; first version: January 2015; launched: February 2015. Total time: 7 months. Total cost, including developer time and beta testing of the web app: $1000 (note that this was developed as part of a demonstration project to be used as an example for other projects, thus the low cost; normal charges for this project would have been $7500).
Case study no. 2: The Social Pounds Off Digitally (social POD) study (mobile app)
The Social POD study was a 12-week RCT of an mHealth weight loss intervention . Overweight adults who owned an Android phone or tablet were recruited (N = 51). The overall goal of the study was to determine whether weight loss outcomes differed between two groups when both groups received theory-based podcasts  but one group used a commercial tracking app (FatSecret app) and the other used the researcher-developed Social POD app, developed to include evidence- and theory-based behavioral weight loss strategies.
Formative work to inform development
A 2-month pilot study was conducted among adults (N = 9) who were overweight or obese (body mass index (BMI) 25–49.9 kg/m2) . The goal of the pilot study was to solicit suggestions for improving the Social POD app for the subsequent RCT. Participant feedback and suggestions were used to inform the revision and development of new features for the Social POD app. The first iteration of the Social POD app included basic features for self-monitoring diet, weight, and physical activity; notifications to self-monitor behaviors; and pre-written user-to-user messages to re-engage those users who discontinued using the Social POD app for a period of at least 48 h (called infrequent users).
Mobile app components
The Social POD app used in the RCT included the same features used in the pilot app, with the addition of a food and beverage database for dietary monitoring and esthetic improvements. Goals were established for participants related to self-monitoring (e.g., tracking calories consumed), with the ability to earn points for achieving goals each day that could be exchanged for prizes. To re-engage users who discontinued using the Social POD app for a period of at least 48 h, a user-user messaging system was developed based on recommender systems similar in function to those used on websites like Amazon and Netflix [25, 26, 27, 28]. Frequent users were prompted via in-app notifications to select a pre-written message to send to infrequent users to try and re-engage them with the Social POD app. A main computational server facilitated all communications from server to users or from user to user. In this context, the main server provided a medium for recording all communications to facilitate analysis of causality and effectiveness of user-pairing strategies.
Researcher data needs
The Social POD research team required a database to collect all user data entered in the app, as well as points earned for using the self-monitoring features of the app. The database allowed the study team to export data to answer research questions related to use of specific features of the Social POD app and evaluate the implementation of the user-user recommendation system.
Who designed the mobile app
Graduate and undergraduate students in the Computer Science department created the Social POD app on the Android platform. A researcher and graduate student from the Department of Health Promotion, Education, and Behavior guided the design of the Social POD app based on participant recommendations from the pilot study. Connections were made between the Computer Science and Health Behavior teams after the Computer Science team spoke at a university conference about their work in the area of health promotion. The research team met weekly to plan the development of the initial iteration of the Social POD app. Following pilot testing, the research team met as needed to refine and test the Social POD app prior to its use in the RCT.
Decision to go with mobile app
The decision to use a mobile app was made to avoid fees for use of text messaging as reminders to self-monitor behaviors. Instead, in-app notifications were used to prompt and alert users. To allow for ease of programming, the Social POD app was available for Android devices only, which proved to be a limitation for participant recruitment in both the pilot study and subsequent RCT.
Total timeline and cost from start to finish: first iteration
Grant obtained for development: February 2013; completed first iteration of the Social POD app: August 2013; began pilot testing of the first iteration of the Social POD app: February 2014; ended pilot testing: May 2014. Second iteration: Began refinement of the second iteration of the Social POD app: August 2014; began RCT recruitment: October 2014; started RCT: January 2015; ended RCT: May 2015; completed data analysis: September 2015. Total time: 34 months. Total cost, including both first and second iteration of the app: $12,161.
Case study no. 3: The Healthy Eating and Physical Activity Mobile (HEPAm) study (web app)
The purpose of this study was to demonstrate the utility of mobile technology as a means to monitor intervention compliance and identify areas of needed technical support in an intervention to increase the quality of foods served and physical activity levels of children in afterschool programs (ASPs). ASPs (N = 109) located in a southeastern state were recruited through an organization committed to improving healthy eating and physical activity (HEPA) across their programs. ASP site leaders were asked to complete an online observation checklist (HEPAm) once per week (i.e., fill out one healthy eating and one physical activity checklist) during their program’s operating hours. All HEPAm items on the observation checklists were aligned with existing HEPA standards and best practices in ASPs. After initial registration with HEPAm, auto-generated weekly text reminders were sent to program leaders’ mobile devices immediately before the start of the program every Monday during the spring school semester (February–June 2015). Data from the HEPAm checklists were downloaded and expressed as a percent of checklists where an item was present.
Formative work to inform development
Items included in HEPAm were informed by a content analysis of current HEPA standards for ASPs , a paper-and-pencil questionnaire developed for a previous intervention study , and feedback from users of the paper-and-pencil questionnaire. A working HEPAm prototype was constructed and pilot tested with end users to gather feedback on the usability, content, and item wording. Participant feedback and suggestions were used to modify question content/structure and the graphical user interface. The first phase of HEPAm (v1.0) included questions on compliance with HEPA standards and a way to monitor progress over time. Based on user feedback, a second phase of HEPAm (v2.0) that included expanded user control over organization and user information was launched in January 2016, with a third phase that will expand the feedback options through an end-user dashboard (v3.0) planned for launch in spring 2016.
Mobile web components
HEPAm collects a snapshot of two areas of ASPs’ daily practices: healthy eating and physical activity. There are separate observation checklists for each area composed of fill-in-the-blank, select-all, and yes/no response scale items for healthy eating (29 items) and physical activity (16 items). HEPAm is intended to be used during program time on a respondent’s mobile device (i.e., smartphone or tablet). HEPAm includes a “view my progress” function that allows users to monitor compliance with HEPA standards by giving healthy eating and physical activity checklist items a score, expressed as a percent of checklists in which an item/behavior was observed (e.g., serve water for snack two out of three checklists/days =66 %). Web links are provided for users to suggested resources for improving scores.
Researcher data needs
The Policy to Practice in Youth Program (P2YP) research team required separate custom queries and export functionality of databases pertaining to (1) healthy eating and (2) physical activity responses differentiated depending on user profile. For example, users could be either a single-site user, where they complete HEPAm at one ASP, or a multi-site user, where they complete HEPAm at two or more ASPs. Data input by site leaders allowed researchers to monitor patterns of compliance with HEPA standards across all sites and identify individual sites that were struggling to meet HEPA standards. In turn, the research team was able to produce materials that addressed overarching challenges with which all sites struggled, as well as tailor materials to program-specific challenges.
Who designed the web app?
An interdisciplinary team comprised of university-based information technology experts, public health professionals, graphic designers, and ASP site leaders (i.e., end-users) was involved in the design of the mobile web app (HEPAm). The web app was specifically designed by the same group that designed the web app for case study no. 1.
Decision to go with web app
The original assessment was paper-based, and researchers were interested in developing a mobile system that would allow ASP staff to easily observe compliance with HEPA standards while on their mobile devices. To encourage compliance, researchers wished to prompt staff to complete the assessment via in-app reminders or texts. Challenges to developing an app-based system included the variety of devices used by staff, the inability to know which devices would need to be supported in the field and regular staff turnover. Therefore, a web app was essential, as it allowed for minor, iterative changes without the need for users to re-download and re-install app updates.
The web app also allowed support for a wide range of older devices that would be very difficult to support with a custom app. Testing of the web app showed support going back to iOS 5 and Android 4.0 (both released in 2010/2011). Because of regular changes to operating system application program interfaces (APIs), supporting older iOS and Android devices would not have been possible with custom apps.
Total timeline and cost from start to finish: phase 1
Initial meeting with technology group: July 2014; prototype delivered: October 2014; follow-up/design enhancements: November 2015; first version: January 2015; launched: February 2015. Total time: 7 months. Phase 2: initial meeting with technology group: August 2015; prototype delivered: October 2015; feedback, fixes and revisions: November 2015; launched: January 2016. Total time: 6 months. Total cost, including phases one and two of the web app: $8100.
Case study no. 4: The Inflammation Management System (IMAGINE) study (mobile app)
The goal of the IMAGINE study is to develop and test a comprehensive diet, physical activity, and stress management intervention to reduce systemic inflammation. The study is a year-long trial (12 weekly intervention classes followed by monthly booster sessions for 9 months) in which eligible participants can elect to participate in the intervention or an information-only control. The study enrollment is staggered, with three cohorts of intervention and additional cohorts of control participants starting over the course of 7 months. The inflammation management system (IMAGINE) study was funded through the National Institute of Health’s Small Business Innovation Research (SBIR) program. As part of the commercialization component of the SBIR-funded study, our team developed a mobile app that would allow patients to complete a screening questionnaire that assessed their Dietary Inflammatory Index (DII) score . The DII is a literature-derived, population-based dietary index that was developed to assess the inflammatory potential of an individual’s diet and place it on a continuum from maximal pro-inflammatory diet to maximal anti-inflammatory diet [32, 33]. One of the goals of the IMAGINE study was to develop this screener and test the usability and validity (as compared to three 24-h dietary recalls) of the screening mobile app. In addition to the mobile app being used as a screening tool, the team is developing a web app as a tool to support intervention study participants when contact is decreased from weekly to monthly in-person visits. The goal of the web app will be to provide support, dietary tracking, and recipes. The choice to go with a web app versus a mobile app for the intervention tool considered cost, time for development, and ease of using the web app across all devices, as well as on desktop computers, especially because the study population is older and may have difficulty using smaller devices (e.g., seeing the screen, using touch to navigate).
Formative work to inform development
For the DII screener, several other commercial diet-related apps were reviewed prior to developing the first phase of the mobile app. In addition, the DII screener mobile app and intervention tool web app will be revised iteratively based on input from current participants. The overall goal of the study’s web app is to develop a basis for a more comprehensive web app that can be used by anyone to help improve their diet, regardless of whether they are involved in IMAGINE.
Mobile app components
All participants enrolled in the IMAGINE study completed the DII screener at baseline. The DII screener mobile app can be downloaded to tablets in a physician’s office or to a user’s phone or tablet and is available for both Android and Apple phones and tablets. It is currently free for download in the Google Play™  and iTunes™  stores.
Researcher data needs
Researchers in the IMAGINE study required the ability to receive the screening tool score from study participants, as well as track downloading and usage worldwide (via distributed apps in Google Play™ or iTunes™). For the present study, participants’ scores were tracked at the baseline visits.
Who designed the mobile app?
52 Inc. (http://www.52inc.com/) is a company based in South Carolina that designs mobile apps for both Android and Apple devices. This company was involved in the SBIR application process and has collaborated with other university and commercial researchers.
Decision to go with mobile app
Because of the SBIR funding mechanism, our team wanted a product that could be quickly scaled up and made available commercially via app repository stores. Use of a mobile versus web app also allowed for the possibility of charging users for app download if that option was eventually needed.
Total timeline and cost from start to finish
Grant period start date for PHASE I award: September 2014; 52 Inc. initiation of work on design of app: September 2014; completion of back-end data storage: December 2014; completion of initial user interface: January 2015; successful completion of algorithms for calculation of the DII: May 2015; release of apps on iTunes and Google Play: August 2015. There is still ongoing work to repair errors and fix functionality for some components of the app. Total cost, including developer time and beta testing of the app: $17,500.
Conclusion: deciding to go with mobile app or mobile web
Benefits and challenges of using two different mobile modalities for public health interventions: smartphone/tablet mobile app versus responsive-design web (web app) in health behavior research
Area of importance for the case studies listed below (case studies 1–4)b
Keeping costs low
Although both options can be costly, web interfaces are generally easier to develop and require less platform-specific programming knowledge.
1, 2, 3
Need to work across platforms and mobile device types (smartphone and tablet)
Although apps can be built for Apple and Android, functionality and features can vary among devices (i.e., phones vs. tablets) and operating system revisions (i.e., iOS 8 vs. iOS 9). In addition, Apple and Android programming and uploading to the related app stores are different. Web apps can work across both mobile and wired devices, as well as on older device operating systems and even devices with embedded web browsers (e.g., Smart TVs).
1, 3, 4
Time for development and refinement
Development time and refinement will depend on the expertise and skillset of your programmers, but web apps generally take less time and are easier to refine. Because the web programming skillset is more general, web programmers are also more common.
This depends on who your population is. If you want your interface to work on multiple wired and wireless devices to accommodate those who may not have a smartphone, then a web app is a better option. However, if your population has access to standardized, newer devices, mobile apps could be useful as well.
1, 2, 3, 4
Data security requirements will differ between mobile and web apps, but consider the target population and how the app will be used. An unlocked phone can give unauthorized users authenticated access to both mobile and web apps, and an open browser on a shared computer can compromise user data in a web app. In both cases, session timeouts would mitigate that risk. Web apps might be at a slight disadvantage, as the front-end user interface is accessible to potential attackers on the open Internet, but back-end data security considerations (of user data within the database) will be essentially the same between mobile and web apps, as data are stored in the same way. Rules and standards compliance will depend on the specific intervention, but in general, data security, interoperability and safety rule compliance will be similar between mobile and web apps. In the case studies presented in this paper, neither method had a significant advantage in terms of regulation or rule compliance.
Researchers need to be aware of applicable consumer privacy regulations, particularly Federal Trade Commission (FTC) rules and best practices for securing consumer data and notifying participants of breaches. Both mobile and web apps must adhere to federal regulations (e.g., Children’s Online Privacy Protection Act (COPPA)) in very similar ways, so again, neither platform has major advantages over the other.
Need to capture photos, location (GPS), or other data
Because web apps are not programs, they are not able to access the smartphone’s camera or GPS to pull this data into the application.
Need for touchscreen interactivity
Web apps use a browser and therefore do not have the same touchscreen interactivity that is possible in an app. For example, if you wanted a user to touch a certain part of the screen and record where the user touched, a mobile app would be required for this functionality. A web app, however, can do basic tracking, such as when a user clicks a link or button on the page.
Processing needs on the device
Web apps do not run on the actual mobile device but instead run from a remote server. If you have an intervention that requires some of the computing power to be pushed to the mobile device, then a mobile app would be required.
Need for notifications to alert the user
Mobile apps on both Android and Apple allow for notifications to be sent to the user, usually displaying as a popup message on the screen, an item in the phone’s notification list or badges (e.g., iOS uses a red circle) next to the app icon. Web apps cannot tap into the phone’s notification system. The workaround for this is to include a notification within the web app page, but this requires a user to first open the web app. A workaround when using a web app is to incorporate text messaging notifications. An automated system can be established to send text messages to users as a way to provide prompts, reminders and feedback. The built-in notification system reduces complexity, as it allows for a variety of individual notifications based on events within the app rather than having to code every scenario within the web app texting system. This may change in the next few years with the development of Push API, which would allow push notifications to be sent via web app .
Ease of updating
Depending on the updates, making changes in a web app will generally be easier than in a mobile app. In addition, changes to a web app do not have to go through a commercial app store (e.g., iTunes) for approvals and verifications.
Need to integrate with sensors or other wearable devices
Both mobile apps and web apps can potentially be used to synthesize sensor and wearable-device data and provide feedback on that data to the user. Only mobile apps, however, could pull data from the device and compile it. For example, use of the MisFit fitness tracker would need to sync with the MisFit app, but the data could then be pulled into your mobile or web app via the MisFit API.
Because newer versions of smartphones are constantly entering the market and system updates occur regularly for Apples and Androids, mobile apps can quickly become out of date if they are not updated. Web apps are less complex to support over multi-year research projects, as compatibility is easier to maintain across multiple generations of devices.
The decision to use a mobile versus web app will depend on numerous factors, including time, cost, expertise, access to programmers, data collection and security needs, and intervention components. The overall purpose and required functionality of the technology used in an intervention, as well as whether the intervention aims at making individual or organizational level changes, will also be important drivers for choice of mobile platform. While cost is presented for each of the case studies, the true total cost, including content that may have been developed as part of previous interventions, was not included, which is a limitation to this paper. Future research studies will most likely continue to integrate both mobile and web app modalities into interventions and will include other non-app components as well, such as sensors, podcasts, videos, and text messaging. The case studies presented here, along with the questions to ask prior to starting an mHealth intervention presented in Table 1, should help future researchers avoid common mistakes in designing web or mobile app-based mHealth interventions and provide a framework for which mobile modalities best suit their research needs.
Compliance with ethical standards
All procedures performed in studies involving human participants were in accordance with the ethical standards of the institutional and/or national research committee and with the 1964 Helsinki declaration and its later amendments or comparable ethical standards.
All the studies presented in this paper were approved by the appropriate institutional review board.
This study was funded by the following entitites: the South Carolina Clinical and Translational Research Institute with an academic home at the Medical University of South Carolina CTSA NIH/NCATS grant number UL1TR000062 (PI: Turner-McGrievy); a University of South Carolina Advanced Support for Innovative Research Excellence—II grant (PI: Turner-McGrievy); NIH grant numbers 1R01GM081793 and P20 RR-016461 (PI: Valafar); the National Institute of Diabetes and Digestive and Kidney Diseases under award number R44DK103377 (PIs: Wirth, Shivappa and Hébert); a Support to Promote Advancement of Research and Creativity (SPARC) grant from the University of South Carolina’s Office of the Vice President for Research (PI: Schoffman); and the National Heart, Lung, and Blood Institutes under award number 1R01HL112787 (PI: Beets). The content is solely the responsibility of the authors and does not necessarily represent the official views of the National Institutes of Health. James R. Hébert is the owner and Drs. Michael Wirth and Nitin Shivappa are employees of Connecting Health Innovations (CHI), LLC, a company planning to license the right to the Dietary Inflammatory Index (DII) from the University of South Carolina to develop computer and smartphone applications for patient counseling and dietary intervention in clinical settings.
Conflict of interest
The authors declare that they have no conflict of interest.
The findings reported have not been previously published and that the manuscript is not being simultaneously submitted elsewhere.
Any previously reported data from the projects described in these case studies have been cited.
The authors have had full control of all primary data and that they agree to allow the journal to review their data if requested.
Informed consent was obtained from all individual participants included in the study.
|Funder Name||Grant Number||Funding Note|
|National Institute of General Medical Sciences|
|National institutes health|
|National Institute of Diabetes and Digestive and Kidney Diseases|
|National Heart, Lung, and Blood Institute|