Indivo X: Developing a Fully Substitutable Personally Controlled Health Record Platform Ben Adida, PhD1,2, Arjun Sanyal, BS1, Steve Zabak, MS1, Isaac S. Kohane, MD, PhD1,2, and Kenneth D. Mandl, MD, MPH1,2 1Childrens Hospital Informatics Program, Harvard-MIT Health Sciences and Technology, Childrens Hospital Boston, Boston, MA 2Harvard Medical School, Boston, MA Abstract To support a rich ecosystem of third-party applications around a personally controlled health record (PCHR), we have redesigned Indivo, the original PCHR, as a web- based platform with feature-level substitutability. Core to this new release is the Indivo X Application Program- ming Interface (API), the contract between the PCHR platform and the end-user apps. Using rapid iterative de- velopment to build a minimal feature set from real-world requirements, the resulting Indivo X API, now in public stable beta, is enabling developers, including third-party contributors, to quickly create and integrate novel fea- tures into patients��� online records, ultimately building a fully customizable experience for diverse patient needs. 1 Background The concept of the Personally Controlled Health Record (PCHR) dates back to the early days of the World Wide Web [13] and is based on a simple idea: a patient should be able to store, consult, and share at will a copy of her entire medical record. This copy is truly patient- controlled. Data are shared with others only when the patient desires and cannot be revoked, hidden, or oth- erwise transformed without the patient���s direct involve- ment. Prominent business thought-leaders believe the PCHR stands to enable cheaper, more flexible, and more effective healthcare, thanks to health-data liquidity [7]. Early prototypes of PCHRs [12], first scalable imple- mentations [11] and successful deployments [6, 14, 5] focused on storing key data elements, including immu- nizations, labs, allergies, and procedures, with an open API to enable alternative user interfaces [3, 2]. The more recent, large-scale industry participants in the PCHR space, Google and Microsoft, provide extensibility at the feature level, with add-on applications that can, upon pa- tient approval, connect to the record and present new fea- tures and visualizations of the user���s data. The default PCHR functionality, however, remains the same. Recently, Mandl and Kohane proposed substitutable health-software platforms [10], where each user can in- dependently substitute one feature implementation for another, sometimes offered by a different vendor alto- gether. Even features central to the platform should be substitutable. PCHRs stand to greatly benefit from this concept, especially in fulfilling more advanced and highly targeted goals of patient engagement, such as chronic condition management or real-time patient- reported outcomes. This need for substitutability was apparent to us, mak- ers of the original Indivo PCHR [11]. With each real- world deployment, first in tracking flu outbreaks, then in integrating with Children���s Hospital Boston���s patient portal, and finally in customizing the Indivo experience for the Dossia Consortium, a significant amount of work was required to deliver the desired user experience in each particular case, putting aside the unneeded features and emphasizing new custom aspects of patient engage- ment. The architecture of prior Indivo releases (and of its competitors) did not lend itself to the easy customization of core features tailored to a population���s needs. This need for deep customization appears to be inher- ent to the PCHR experience. For example, a patient with diabetes should be able to replace the generic ���Labs app��� within their PCHR with one tailored to highlight HbA1C and renal function, combined in one dashboard with lat- est weight and glucose measurements loaded from wifi- connected scale and blood glucose monitor. Meanwhile, a new parent might add a ���Baby Development app��� that replaces the default PCHR landing screen with their child���s latest growth chart. With this extensive customiz- ability, the PCHR becomes easier to use, more in tune with the user���s needs, and thus a far more effective tool in personal health management. In this paper, we describe the design and development of Indivo X, an evolution of our flagship PCHR, to sup- port full substitutability via Web-based extensions, and specifically of the Indivo X Application Programming AMIA 2010 Symposium Proceedings Page - 6

Figure 1: A clinical-trials matching app, built by TrialX, embedded within the Indivo X UI and talking to the Indivo X API. Indivo X serves the app-list on the left and the patient-context across the top, while the app runs on a separate server, hosted by TrialX, displayed in an HTML IFRAME. Interface (API). The goal of Indivo X is to provide a generative platform that accelerates the development of novel personal-health features. The Indivo X source code and documentation, including the API and video demon- strations, can be found at http://indivohealth. org. Indivo X is released under an open-source license. 2 Methodology: Iteration, Parallel App Design, and proven Web-based Tools The Indivo X API was developed in a series of rapid iterations informed by parallel development of, first, research-oriented personal health apps, then, apps used for clinical purposes at Children���s Hospital Boston. Sub- sequently, the API was finessed with feedback from ex- ternal developers including academic computer scien- tists, practicing physicians, hospital IT staff, and health- software startups, who were provided access initially to a staging server, then to the source code. The most useful Web APIs ��� Flickr, Amazon S3, Face- book, OpenSocial, etc.��� provide, rather than an expan- sive and complex interface, a limited, focused, and gen- erally stable feature-set. The constraints of the API typ- ically encourage developers to keep their use of the API simple and thus robust. To mimic these successes, we relied on five design principles: 1. standards: we started with web-friendly standards including REST [8], oAuth for authorization dele- gation and machine authentication [9], XML with openly defined schemas for data and metadata. 2. open-source: we used established open-source toolkits for rapid development, including the Django/Python web toolkit [1] for Model-View- Controller design and database abstraction, the PostgreSQL relational database for robust data stor- age [4], and JavaScript MVC plus jQuery for a mod- ern ���Web 2.0��� user interface. 3. use-case-driven requirements: we set up separate teams to develop needed personal health applica- tions in parallel, in order to generate real-world re- quirements for the API, 4. minimalist feature set: we regularly pushed back on these teams��� feature requests to keep the API simple and ensure that new features were added only when truly necessary. 5. unified user experience: we defined a unified vi- sual experience similar to Facebook, OpenSocial, and other widget platforms like iGoogle: the In- divo X UI lists the active apps and loads the cur- rently selected app from a different web server into an HTML IFRAME. The user sees a seamless inte- gration of the two (Figure 1). We specifically set out to build: a patient survey en- gine, a genomic messaging system, and a patient-social- network integration. Then, a few months into develop- ment, we invited Children���s Hospital Boston���s IT team to adapt their custom PCHR interface to the new Indivo X backend (Figure 2). This parallel approach was, at times, AMIA 2010 Symposium Proceedings Page - 7