A case study in open source innovation: developing the Tidepool Platform for interoperability in type 1 diabetes management.

OBJECTIVE: Develop a device-agnostic cloud platform to host diabetes device data and catalyze an ecosystem of software innovation for type 1 diabetes (T1D) management.
MATERIALS AND METHODS: An interdisciplinary team decided to establish a nonprofit company, Tidepool, and build open-source software.
RESULTS: Through a user-centered design process, the authors created a software platform, the Tidepool Platform, to upload and host T1D device data in an integrated, device-agnostic fashion, as well as an application ("app"), Blip, to visualize the data. Tidepool's software utilizes the principles of modular components, modern web design including REST APIs and JavaScript, cloud computing, agile development methodology, and robust privacy and security. DISCUSSION: By consolidating the currently scattered and siloed T1D device data ecosystem into one open platform, Tidepool can improve access to the data and enable new possibilities and efficiencies in T1D clinical care and research. The Tidepool Platform decouples diabetes apps from diabetes devices, allowing software developers to build innovative apps without requiring them to design a unique back-end (e.g., database and security) or unique ways of ingesting device data. It allows people with T1D to choose to use any preferred app regardless of which device(s) they use.
CONCLUSION: The authors believe that the Tidepool Platform can solve two current problems in the T1D device landscape: 1) limited access to T1D device data and 2) poor interoperability of data from different devices. If proven effective, Tidepool's open source, cloud model for health data interoperability is applicable to other healthcare use cases.

BACKGROUND AND SIGNIFICANCE

Diabetes is one of the largest healthcare problems in the United States, with an estimated 29 million people having the disease (21 million diagnosed cases). Each year, the United States sees 19 000 new cases of type 1 diabetes (T1D). T1D is the second most common chronic condition in children, trailing only asthma. T1D, which requires the replacement of insulin via subcutaneous injection, is unique among chronic diseases in its heavy reliance upon patient self-management. Patients make minute-to-minute decisions about their insulin dosing based on a multitude of factors such as current blood glucose (BG) level, food intake, and activity level. There is a very narrow margin for error, especially in children. Taking either too much or too little insulin can cause dangerous and sometimes life-threatening high or low BG levels. To avoid this, insulin dosing regimens must be adjusted frequently and individually for each patient. Such personalized fine-tuning requires significant effort and is seldom done.

The introduction of insulin pumps has made it possible to deliver insulin continuously and with great precision. Pumps more closely mimic physiological insulin secretion, giving variable “basal” rates throughout the day and delivering additional boluses for each meal or snack, or to bring down high BG levels. The use of continuous glucose monitoring (CGM) devices has allowed for tighter BG control, which has been shown to reduce the rates of diabetes complications.

Diabetes devices store a patient’s data, including insulin dose history, insulin pump settings, and BG values from BG meters and CGM devices. These data can be downloaded from devices into historical reports by patients or healthcare providers. Analyzing these reports can help a provider or patient identify BG trends and effects of insulin on BG levels. A patient’s insulin regimen can then be adjusted based on this analysis combined with a patient’s recall of her activities and life events. This individualized fine-tuning of insulin doses, known as “flexible intensive insulin therapy,” has been shown to improve quality of life and glycemic control in people with T1D. Despite this, only a small percentage of people with T1D use these historical reports to retrospectively review their device data and look for patterns to inform future dosing decisions. Instead, most people with T1D use only their most recent BG reading to make insulin dosing decisions.

Potential reasons for this lack of retrospective review of diabetes device data include the data silos and workflow challenges that exist with device downloading and data interpretation. Custom cables and proprietary software, often requiring different computer operating systems, are needed to download and view device data. Because patients may use multiple devices from different vendors to manage their diabetes, it is often impossible for a patient to import all of her device data into one software application. Moreover, each software application has a unique user interface and data display paradigm, which would be akin to each EKG manufacturer developing their own data acquisition and display method rather than conforming to the standard.

Vendors have from time-to-time partnered with each other to directly pair their devices and create device-to-device interoperability—for example, an insulin pump from one vendor with a CGM from another vendor. Though these pairings consolidate real-time displays to improve the patient experience, they fail to address the underlying issue of proprietary data silos and their impact is thus limited. Numerous efforts have tried to facilitate an integrated download and data display from multiple vendors’ devices. Sweetspot, targeting physicians’ offices as customers and using kiosks in physicians’ offices to upload device data, failed to achieve broad commercial success and was acquired in 2012 by CGM vendor Dexcom. Diasend sells proprietary software, offering a hardware upload hub that sends device data to the cloud, creating an integrated data visualization. Glooko, first funded with venture capital in January 2012, has to this point focused on devices (BG meters) and visualizations aimed at the type 2 diabetes market. In 2015, however, Glooko announced it would begin integrating insulin pumps and CGMs. The grant-funded Ambulatory Glucose Profile is a proposed standard for the display of data from any vendor’s CGM, rather than an integration of multiple devices into one display. A different approach toward device interoperability is the forthcoming set of Institute of Electrical and Electronics Engineers (IEEE) standards for diabetes device data protocols, based on work from the University of Toronto. Both the Ambulatory Glucose Profile and IEEE device standards differ from companies like Sweetspot, Diasend, and Glooko in that the standards will require implementation by device vendors. Despite so many efforts, the diabetes device data ecosystem remains fragmented and siloed.

Further fragmenting the ecosystem are the hundreds of mobile apps developed to help patients track and review diabetes data. Apps typically do not interface with each other and apps not developed by device makers do not connect with devices to automatically retrieve data. Users must thus manually enter BG values and insulin doses into each app, an inefficient, error-prone, and burdensome process. Vendor-developed apps that automatically upload device data, like iBGStar, have largely served to sustain closed ecosystems rather than enabling true interoperability. Most apps either lack a data export function or export data as a document (e.g., PDF file) rather than as discrete values. For these and other reasons, diabetes mobile apps have as of yet failed to reach broad adoption.,

OBJECTIVE

Our goal was to create a cloud-based, device-agnostic software platform that could download and integrate raw data from any diabetes device. Our primary aim was to facilitate easier access to these currently siloed data. This device data interoperability would then enable the creation of an ecosystem of innovative diabetes management apps. As such, to demonstrate the utility of our platform, our secondary aim was to develop an app that would incorporate data from different devices and facilitate conversations between T1D patients and providers.

MATERIALS AND METHODS

Existing market dynamics make it difficult for the diabetes industry to address the problem of interoperability and instead encourage proprietary vertical silos of devices, data storage, and software. Our strategy was to instead draw on the experience of the communications industry, where companies providing proprietary and closed internet access like Prodigy, AOL, and Compuserve gave way to the open model of the World Wide Web., Just as cultivation of the Internet required non-profit funding, we felt the same would be true for an open data platform for diabetes management. We thus formed a non-profit corporation, Tidepool (tidepool.org), hypothesizing that a transparent process and organizational structure were critical to establish a new paradigm for management of diabetes device data.

Being nonprofit ensures that Tidepool in perpetuity prioritizes interoperability and open access over data silos and claims on market share. In this way, Tidepool aims to bolster the entire diabetes data ecosystem rather than competing over existing customers. If Tidepool is successful at catalyzing an open ecosystem with a large selection of diabetes apps, this may grow the overall device market, allowing all companies to sell more devices. The nonprofit, transparent structure facilitates a collaborative effort between our interdisciplinary team of academic endocrinologists, clinical informaticists, software developers, user interface experts, and technology entrepreneurs, most of whom either have T1D or family members with T1D. The nonprofit model has also helped Tidepool garner enthusiastic support from the T1D community at large, including patients, families, advocacy groups, and device makers.

A potential disadvantage of non-profit status is the inability to secure venture capital funding. Because venture capitalists have focused diabetes investments on the larger, more lucrative type 2 diabetes market rather than T1D, this concern is minimized for Tidepool. Tidepool’s startup funding has come from private philanthropists and granting agencies. Rather than relying on these sources indefinitely, Tidepool believes it can operate as a self-sustaining non-profit business, generating revenue through data hosting services. There are early indicators that this model can be successful.

In addition to choosing a non-profit status, our second major strategic decision was to create open-source software. We were inspired by the “open mHealth” model, believing that T1D is a particularly well-suited use case. The use of open-source software is consistent with our goals to reduce barriers to entry for new app developers, to foster collaboration, and to create software that is safe and secure. Identified factors favoring the use of open-source software in healthcare include: allowing universal access to the software, ensuring public scrutiny of the code, providing users the ability to add functionality and fix bugs without waiting for a company to do it, providing a toolkit that allows researchers to expand upon the software, and improving development efficiency. Because Tidepool will continually employ developers to maintain the software, code contributions from the open source community will augment rather than sustain the platform. Tidepool chose to use the Berkeley Software Distribution open-source license, a highly permissive license that allows third parties to leverage and repurpose any or all Tidepool code, maximizing the code’s potential impact. To date, nine employees and fifteen open source contributors have created code for Tidepool.

Tidepool’s development process is transparent beyond being open-source. All planning and technical documentation is openly published at GitHub. Third parties are free to use Tidepool’s code to run their own private installations, or they can apply for access to use Tidepool’s hosted data store for their own applications, a model used by many successful companies like WordPress. Tidepool’s nonprofit model and open ecosystem stand in contrast to the corporate philosophies and structures taken by SweetSpot, Diasend, and Glooko. Our hypothesis is that achieving broad impact on T1D device interoperability may require this unique combination of attributes.

The collaboration between academia and technologists has thus far proven critical, providing a broad set of resources. The University of California, San Francisco (UCSF) offered a healthcare-specific entrepreneurship course where we formulated potential business models. UCSF’s Center for Digital Health Innovation is working to integrate Tidepool with its electronic health record (EHR). Clinical researchers on our team reinforced the need to prioritize validation and evaluation of the Tidepool Platform and subsequent apps on meaningful patient-oriented and clinical outcomes, building the necessary structure into the product. Reciprocally, Tidepool’s technical and product design team have provided expertise not typically available in-house at academic institutions. Together, we aimed to surge forward with the agility of a startup company to create a modern, user-friendly system, while developing the meaningful medical content and clinical workflows necessary for a useful health tool.

RESULTS

The Tidepool Platform

The Tidepool Platform provides a hub for patients’ diabetes device data, along with open access for third-party apps to communicate with the platform using RESTful application program interfaces (APIs). The Tidepool Platform is device-agnostic, ingesting data from any vendor’s device(s) and then allowing any app to connect to the platform to use that data (Figure 1). This eliminates the current one-to-one relationship between T1D device hardware and software (Figure 2). As the foundation for future development of T1D apps, the Platform was built to handle “back-end” components such as security and authentication, data storage, and HIPAA compliance. Thus, software developers can focus on building engaging and useful apps without having to worry about developing a new back-end themselves. Of note, Tidepool’s software is still in an early stage of implementation, currently in use by a small group of beta testers and in a pilot study at the UCSF as well as by clinics associated with the ReplaceBG study coordinated by the Jaeb Center for Health Research.

Figure 1:

Diabetes device data flow with Tidepool Platform.

Figure 2:

Diabetes device data flow before Tidepool Platform.

Blip App

In parallel with development of the Platform, Tidepool created Blip, the first app built on the Platform. Blip combines an individual patient’s data from multiple devices into a single integrated display, allowing data visualization and interpretation. In the example in Figure 3, data was combined from a Medtronic insulin pump, Dexcom CGM device, and a Bayer Contour glucose meter. “Sticky notes” indicate comments entered via a patient-facing mobile app about food, exercise, or other relevant life events. The integrated visual interface allows providers or patients to look for relationships between carbohydrate intake, insulin boluses, and rising or falling glucose levels.

Figure 3:

Blip App screenshot.

The Tidepool Platform: Engineering and Architecture Principles

In addition to being open-source, we consider 6 other engineering principles as core to the Tidepool Platform.

Small, Modular Pieces

Code built in small, modular pieces makes each element more manageable to design, build, and test, as well as allowing easy isolation in the case of a problem. In an open-source environment, having small pieces makes it easier for many developers to contribute code. The Tidepool Platform is currently composed of 16 different components in 5 groups (Table 1), working together to create the desired functions of the system (Figure 4).

Table 1:

Tidepool Platform code modules.

Code Grouping	Group Function	Key Components of Each Group
Server management	Manages communication between the various components of the Tidepool Platform	Server assignment Discovery Request routing
User data storage	Manages users and communications to and from the user databases	Management of user login data User metadata and demographics Authorization Messages and notes
Medical data storage	Stores and retrieves medical data	Medical data uploader Medical data processing and ingestion Medical data retrieval
Libraries	Collections of useful functions to make it easier to work with the code	Time and date manipulation Communications with other bits of the API Assistance for software developers
Applications and their support	The parts of the system that are visible to the end user	Application for viewing and reviewing diabetes data in context (Blip) Visualization library Mobile-compatible communications app

Figure 4:

Tidepool Platform architectural diagram.

Modern web design

Tidepool uses modern software architecture (see Table 2), including designing the software around RESTful principles, which the Agency for Healthcare Research and Quality (AHRQ) recently called the “foundation” of an interoperable healthcare system. In a RESTful system, major system components are both accessed by and communicate using standard (rather than proprietary) web protocols. This makes it easier to design and deploy the pieces individually and independently, which aids in robustness and ease of maintenance. It also reduces the complexity for client software, as there are mature tools in every programming language for communicating with RESTful APIs. This standard toolkit lowers the barriers to development.

Table 2:

The Tidepool technology stack.

Function	Technology or Service Used
Hosting	Amazon Web Services (HIPAA-compliant dedicated instances)
Data storage	MongoDB, Amazon S3
Server architecture	JavaScript/NodeJS, Golang
Key server libraries	Express, restify, lodash, async, rxjs
Client architecture	React
Data visualization	D3

HIPAA, Health Insurance Portability and Accountability Act

Tidepool’s server systems use a set of interoperating RESTful protocols that are publicly accessible online. Tidepool’s apps use those protocols to communicate with the servers. A JavaScript library that encapsulates client communications with the Tidepool Platform is also freely available online.

Cloud-computing

Tidepool’s “Platform as a Service” model relies on cloud-computing (Figure 5). The cloud model, with centralized data storage and online access to computing resources, allows access to data from any place, at any time, from any source. Cloud computing is still nascent in healthcare despite being standard in many other business applications. Schweitzer et al. noted that cloud-based healthcare software could be more efficient and less expensive than traditional enterprise software, could promote interoperability and data exchange, and would be more responsive to changes. By relying on an intermediary vendor, cloud computing’s potential limitations include security and privacy risks as well as the risk of service interruption.

Figure 5:

Tidepool Platform cloud diagram.

Client software products for the Platform are built as web applications using JavaScript and HTML. Storing and delivering software over the web means that users can always access the most recent software version, seamlessly benefiting from the latest advancements and bug fixes.

Agile software development

Tidepool uses agile software development methodology, which prioritizes the flexibility to adapt to changing product needs over adhering to a pre-specified project plan as is done in “waterfall” development models. Healthcare customer needs are complicated and often poorly understood at the outset. Agile methodology allows many stakeholders (i.e., clinicians, researchers, patients, caregivers, and IT departments) to shape software development over time.

Tidepool’s development cycles are limited to 2-week time periods. Any functionality estimated to require more development time is broken into sub-deliverables. This helps Tidepool try to quickly deliver functionality to end-users, often with multiple new software releases delivered in a 2-week period. These 2-week periods are referred to as “sprints.” The sprint methodology gives Tidepool a structure to maintain course when priorities remain constant or adapt quickly as priorities or user needs shift.

User-centered design

User-centered design involves iterative cycles during the design and development process that involve user input at every stage. While this approach can “maximize user motivation and engagement, reduce system failure or dramatic revisions, and provide greater feasibility and sustainability,” one review found that only 18% of mobile diabetes apps studied described a user-centered design process.

By contrast, user-centered design has been a core process in developing the Tidepool Platform and its initial app for data visualization, Blip. In its first 18 months, Tidepool has conducted 502 interviews with patients, clinicians, researchers, device makers, and software developers. With few exceptions, these meetings were conducted either face-to-face or via video conference, consistent with “Lean Startup” methodology. As Tidepool meets with users and perceives the need for new functionality, an application or sub-component of an application is coded into a functioning prototype. Over the course of several weeks, that prototype is shared with dozens of constituents. Feedback is collected in real time and additions are made daily, so often no two testers will experience the identical prototype.

Early prototype versions are also shared with patients and their families in a “beta” release. The beta is distributed via the web, along with assignments for the user to complete that provide structured feedback. Through April 2015, 49 patients and families had been invited to participate in the beta, with 32 invitees participating and submitting feedback. Concurrent with this user-centered design process, we have been collecting user data and feedback on the Blip app as part of an IRB-approved pilot study at UCSF.

Security and privacy

The Platform uses a government-standard algorithm for encryption and data are encrypted both at rest and during transport. User data, such as log-on information, is stored and encrypted separately from patient data, which includes health and demographic data. All pieces of the system are located behind a firewall (Figure 4); only the router is accessible to the global Internet. An app server delivers client applications like Blip to individual computers, which then communicate to the Tidepool cloud to provide user services and medical data.

The Platform has undergone security assessments following the National Institute of Standards and Technology controls at 2 large healthcare systems. These include questions about: platform architecture, data management practices (policies for storage and access, encryption, and data breaches), restrictions on external access (firewalls, access keys, and security roles and permissions), and third-party vendors used (including business associate arrangements). Tidepool has implemented the Platform in a way that meets all federal Health Insurance Portability and Accountability Act (HIPAA) requirements and has signed business associate agreements with UCSF and with Amazon Web Services (required because Tidepool uses Amazon’s cloud servers).

DISCUSSION

The Tidepool Platform offers many opportunities to improve technologies that enable clinical care and research for T1D (summarized in Table 3 and described below).

Table 3:

Potential clinical and research advantages of an open diabetes platform.

Current State	Open Platform
Near one-to-one relationship between device and application	Any application can use data from any device
Mobile apps require manual data entry by the user, leading to user burden and transcription errors	Mobile apps automatically access and collect device data
A provider must learn to interpret data presented in each unique software application and visualization format from each device vendor (or choose only one device to prescribe to their patients)	A provider selects and gains expertise using one software application of choice while still allowing patients the freedom to choose to use whichever devices they prefer
Patients may use devices (e.g., one pump and one continuous glucose monitoring device) from different vendors but are forced to sacrifice data interoperability	Patients who choose any permutation of devices are able to use device data in an integrated fashion
Mobile app developers must each develop a unique vertical product stack including back-end features (e.g., secure and private data storage)	App developers can focus on developing front-end, user-facing apps that integrate with the back-end of the Tidepool Platform
Diabetes software only uses and shows data from diabetes specific hardware	Diabetes software can incorporate data from any source, including trackers for fitness/activity, heart rate, and food
Device companies must devote resources to software development	Device companies can focus efforts and resources on hardware, their area of expertise
Clinical research studies utilizing devices are restricted in the permutations of devices they can use	Clinical research studies can use any combination of devices
Developing new clinical decision algorithms in research studies requires many slow iterations of testing, refinement, and then pushing out the updated algorithm for testing again	Researchers can more efficiently study clinical algorithms, pushing the algorithms out to users through the cloud and rapidly getting feedback about efficacy
Researchers must manually collect data for each new retrospective study they conduct	Researchers can access and query a comprehensive clinical dataset that is already collected

Potential Advantages for Diabetes App Development

Apps built on the Tidepool Platform can offer unique front-end functionality while sharing a common data structure and back-end (Figure 6). This open access to a shared back-end lowers the barrier to entry for developers with creative ideas for new diabetes apps. Apps can easily be interoperable with other apps and developers will have broader access to data and other functionalities than they would have if they built a standalone app. Interoperability of health technology can potentially improve patient safety, protect against lost and missing data, and improve efficiency of care.

Figure 6:

Tidepool Platform conceptual diagram. 3P = 3rd Party; AP = Artificial Pancreas; Nutshell and Sonar = Decision support apps in development by Tidepool; EHR = Electronic Health Record; API = Advanced Programming Interface.

Other industries have similarly benefited from a move from closed and proprietary ecosystems to open, standards-based, multi-vendor ecosystems. This “co-opetition” provides greater flexibility due to more potential device permutations, lower costs, and movement by companies toward higher value activities.

Potential Benefits to Clinical Care

The Tidepool Platform will allow people with diabetes to identify and use apps that uniquely address their individual needs, choosing apps based on functionality rather than based on whichever input device(s) they are using. Promoting connections between apps enables the inclusion of data sources, such as food and activity tracking apps or heart rate sensors, which are not typically used alongside BG or insulin data. Putting these data alongside more traditional diabetes device data improves context, facilitating the review of life events that coincide with a diabetes-related event such as a hypoglycemic episode. Prior evidence has shown that integrating contextual data is helpful in T1D management.

Cloud-based apps built for the Tidepool Platform, like Blip, can facilitate the sharing of diabetes device data and ongoing communication between patient and provider. This communication is often lacking, creating a barrier to improved glycemic control., More frequent clinician review of patient-generated diabetes data along with feedback to the patient has been shown to improve hemoglobin A1c. Developing rapid feedback loops between a patient and provider could facilitate “teachable moments,” whereby providers could guide patients toward learning how specific life events impact glycemic control. Integration of diabetes device data with EHRs could facilitate these rapid feedback loops by placing diabetes device data into healthcare provider workflows. Having a single open-source platform like Tidepool could facilitate EHR integration since health IT departments would only need to integrate one back-end data source as opposed to creating a unique custom integration for each vendor device and application.

As development of closed-loop “artificial pancreas” systems progresses,, there is a need for safety and monitoring software. The Tidepool Platform can fill this need, providing cloud-based data hosting, visualization, and analytic tools that would allow patients, providers, or regulatory agencies to track data from the artificial pancreas.

Potential Benefits to Diabetes Research

A cloud-based platform provides researchers with opportunities that were previously difficult to attain or unavailable with installed client software. Cloud-based storage allows data to be stored once but accessed by any number of authorized users. Thus, for example, Tidepool might give patients the ability to contribute their data to an anonymized research database. Any researcher would then be able to access this comprehensive dataset of openly available, high-quality, contextualized diabetes device data, allowing novel research questions to be answered. Such a research database could be used to help simulate and test artificial pancreas algorithms before they are applied in patients.

Using the Tidepool Platform for data collection and hosting would relieve clinical researchers of the need to independently set up a data collection system for each research study, improving efficiency and decreasing research costs. This infrastructure is already being used to support a multi-center clinical study involving 275 patients.

Clinical researchers will have new opportunities to evaluate the efficacy of T1D software. The current one-to-one bond between device and software has created few opportunities to compare the efficacy of T1D software independent of the devices collecting the data. In studies showing improved quality of life and clinical outcomes for users of insulin pumps and CGM devices, device-software combinations have been analyzed rather than individual components. Only 2 published studies have compared patients on insulin pumps who used the vendor-provided software to those on insulin pumps who did not use the software.,

Researchers could use the Tidepool Platform and cloud analytics tools to evaluate user engagement with and efficacy of specific components or combinations of components of diabetes apps. These more precise insights are currently lacking in most published diabetes mobile app studies, which tend to follow the “black box” model of evaluation. Usability testing methods not typically seen in healthcare might be possible, such as “A/B testing,” where researchers can perform repeated usability tests of small variations in their apps with a high frequency of iterations.

CONCLUSION

Both the Tidepool Platform and its development process, if proven to be effective, can serve as models for future healthcare technology innovation. The Tidepool Platform’s open software code is adaptable for use beyond T1D in other chronic diseases that rely on patient-generated multi-sourced data, such as type 2 diabetes, asthma, or congestive heart failure.

Tidepool’s success would illustrate that an “open mHealth” model can facilitate interoperability and would suggest that proprietary vendor data silos are a restrictive and outdated model. Tidepool, though still in its early stages, has already catalyzed a vibrant dialogue and meaningful contributions from T1D advocacy groups, healthcare providers, researchers, software developers, and device manufacturers worldwide. Tidepool has stimulated a virtuous cycle in the T1D device ecosystem, as a majority of diabetes device manufacturers have committed to opening their data protocols to Tidepool. The future implementation of data protocol standards will create more efficiency in this open innovation ecosystem, obviating Tidepool of the need to implement device protocols one at a time.

We hope that apps built on the Tidepool Platform—like Blip—can facilitate better self-management and clinical diabetes outcomes through improved data accessibility and improved feedback and communication between patient and provider. We foresee that the Tidepool Platform will spur the development of many useful new apps for T1D beyond Blip, meeting patient and provider needs in ways that were not previously possible when data was trapped in silos.

COMPETING INTERESTS

S.A. owns publicly traded shares in Dexcom and Tandem, and serves as member of the Scientific Advisory Board for Tandem. H.L. and B.A. are paid employees of Tidepool, a nonprofit corporation. H.L. owns publicly traded shares in Dexcom.

FUNDING

Tidepool has been funded by grants from the JDRF, the Goldsmith Foundation, The Helmsley Charitable Trust, and by private philanthropy. J.W. receives research support from an NIH K12 award, DK094726. A.N. has received research support from an NIH T32 grant.