Research and applications Figure 5 The envisioned SMART ecosystem. Health IT systems, such as electronic health records (EHR), personal health records (PCHR), and health information exchanges (HIE), that use the SMART application (app) programming interface (API) or a portion of it marshal data sources and present data simply, reliably, and consistently to apps. Apps are made available, under a business model to be speciﬁed, in one or more app exchanges. Administrators of individual SMART container installations (eg, vendors, chief information ofﬁcers, practice leaders) can choose which apps are made available to their end users. End users can create a ‘dashboard’ of apps that they use in their workﬂow. data elements including patient demographics, encounters, and vital signs, by issuing queries against the Cerner published ‘Millennium Objects’ SOAP interface, and translating results to SMART RDF on-the-ﬂy. Early experience indicates that on-the-ﬂy translation is feasible, but pre-fetching and caching results may be required for acceptable performance on larger datasets. The source code for the translation layer, including hooks into the SMART Reference EHR, is available from https://github.com/chb/ smart_grails_proxy. In addition, Microsoft has produced a proof- of-concept SMART-enabled version of their HealthVault PCHR. Charter apps We have created several charter apps, brieﬂy described here. The ‘Cardiac Risk’ app is based on a conceptualization by David McCandless of a consumer-friendly presentation of cardiac risk based on laboratory information about cholesterol, demographics, and risk factors. The image appeared in Wired magazine22 and is posted on McCandless’ website for use under the Creative Commons license.23 The SMART team, program- ming against the SMART reference container, created a func- tional, interactive app faithful to McCandless’ aspiration. Figure 4 shows the app running in the SMART reference container, on the Indivo PCHR and the i2b2 analytic platform. The ‘Adherence’ app accepts medication fulﬁllment histories, displays gaps in medication possession, and predicts future non- adherence.24 The ‘Blood Pressure’ app is the ﬁrst SMART app designed for a deﬁned population of real-world clinical users; developed according to clinician-derived speciﬁcations at the Children’s Hospital Boston, it connects to a SMART-enabled Cerner EHR and monitors trends in blood pressure, ﬂagging hypertension in pediatric patients by applying NIH guidelines that incorporate a child’s age, gender, and height. Upcoming research areas and strategic decisions App distribution and access While the full business model for distribution of SMART apps is still emerging, a few principles are clear. First, while the SMART 602 API will remain open source and available under the Apache 2.0 license, there is no such obligation for externally developed apps, which may be open or closed source code. Second, we are not committed to a single iTunes-like app store, but rather envision that there may be one or several app exchanges. Assessing quality of apps will be a multi-input process, no doubt involving local opinion leaders, professional organizations, and possibly certiﬁcation bodies. Administrators of individual SMART container installations (eg, vendors, chief information ofﬁcers, practice leaders) can choose which apps are made available to their end users (ﬁgure 5). End users can create a ‘dashboard’ of apps that they use in their workﬂow. Security concerns may inform deployment decisions at a given site. For example, a hospital may want to install all SMART apps on locally hosted servers within the hospital intranet to help ensure the proper treatment of protected health information. By contrast, a PCHR may have much greater tolerance for running cloud-hosted apps, allowing individual patients to determine with which apps they wish to share data. Write API To date, the SMART API provides a read-only view of the patient record. We have constrained the API in this fashion in order to lower the barriers for existing health IT systems to adopt SMART and beneﬁt from a growing community of apps. Allowing apps to write data back to a container considerably increases the complexity of implementation. We plan to add write capabilities gradually, as support for the read-only API grows. Standards With a goal of maintaining an open stack, we use web standards extensively (eg, HTML, JavaScript,25 OAuth, RDF) and medical standards for coding systems (eg, RxNorm, LOINC,25 SNOMED). The space of open clinical data models is underde- veloped. There is no widely implemented, developer-friendly open standard, for example, for what a medication, fulﬁllment, J Am Med Inform Assoc 2012;19:597e603. doi:10.1136/amiajnl-2011-000622