Research and applications systems have heterogeneous methods of authentication and authorization. To allow a single app to run against heterogeneous systems, the SMART speciﬁcation standardizes the authentica- tion of API access but allows an underlying container to apply its own authorization mechanisms. This means that, when an app makes an API call, the container can be certain that the call has not been forged. But the container retains full power to determine whether the app is, in fact, authorized to retrieve the data it has requested. Two authentication schemes are employed, one for SMART Connect and one for SMART REST calls. Since SMART Connect calls happen in-browser, they are by deﬁnition made in the context of an established user session. In this case, no additional authentication is explicitly required by the SMART speciﬁcation. SMART RESTcalls, on the other hand, are made server-to-server and are signed using a token and shared secret via the OAuth 1.0a protocoldan open protocol for secure API authentication.10 The scope of access tokens is kept narrow so that, for instance, an app requires a separate access token for each patient record it wishes to query. Figure 3 illustrates the SMART API functionality. User-interface apps SMART user-interface apps are user-facing, browser-based apps written as HTML5 web apps, which are platform-independent and run in all modern web browsers on desktops or mobile devices. They integrate into an existing health IT system via the HTML inline-frame element. If an existing health IT system is web-based, SMART apps may be integrated by adding an IFRAME to an existing web interface. If an existing health IT system runs a ‘thick client,’ inclusion of a SMART app may require augmenting the client with a ‘web view’ widget or launching a separate browser instance. Background apps Background apps employ the same API calls as user-interface apps but perform data processing and analysis without the need for user Figure 3 At the center, a web browser window presents two principal components: (1) a white border region belongs to the SMART container, displaying a list of available applications (apps) as well as patient context; (2) a larger gray block belongs to a single ‘Cardiac Risk’ app. As illustrated, the ‘Cardiac Risk’ app can request data from the container directly inside the browser via SMART Connect; an app with a back-end component may request data with a server-to-server call via SMART REST. In either case, the SMART-enabled electronic medical record or personally controlled health record responds with the same SMART RDF data payload. 600 interaction. Since these background apps do not run in the context of a web-browsing session, they must access patient data via SMART REST, not SMART Connect. In addition, SMART pro- vides a preliminary interface for background apps to loop through the patients in a container one-by-one, fetching and processing data for each. Hence, background apps can be used for batch- processing tasks such as executing clinical rules or computing quality measures. Background apps might also be used to simulate population-level queries by serially evaluating one patient at a time, although this approach is unlikely to scale to large datasets. RESULTS In addition to development of the API, the ﬁrst-year efforts centered on SMART-enabling select containers and creation of a small set of charter apps to demonstrate functionality and inform system design. Apps challenge A focal point of the ﬁrst year was the SMART Apps Challenge. Sponsored by the Ofﬁce of the National Coordinator for Health Information Technology, we launched a developer-focused chal- lenge on the Administration’s Challenge.gov website.11 The contest, offering a US$5000 prize and judged by a blue ribbon panel,12 was announced by the President’s Chief Technology Ofﬁcer, Aneesh Chopra, at the 2010 mHealth Conference during his shared Keynote with Bill Gates,13 and on his White House blog.14 The SMART team created a reference container deployed in a ‘sandbox’ environment for challenge entrants populated with a hybrid of anonymized and synthesized clinical data for 50 sample patients, published for open use and redistribution.9 The challenge was to build a SMART app that provides value to patients, providers, or researchers, using patient-level data delivered through the SMART API. There were 15 entries with functionality such as generating multi-lingual patient-facing medication instructions, or providing a public health dashboard that links EHRs with immunization registry and syndromic surveillance data. The winner was the Meducation app by Polyglot. Meducation pulls the patient’s medication list across the API and joins it to simpliﬁed patient-friendly instructions for the individual medi- cations in 12 languages. Polyglot is a small company whose business model would clearly be advanced by SMART API access to the wider IT infrastructure. The challenge achieved several objectives: (1) forcing an early (10 months into the project) release of the API and sandbox; (2) necessitating early develop- ment of charter apps (see below); (3) requiring extensive docu- mentation and creation of website and promotional materials; (4) widely publicizing the platform; (5) for only a US$5000 investment, generating 15 intriguing apps; (6) demonstrating a key property of SMARTdthe challenge apps were able to run, unmodiﬁed, across multiple platforms. Building SMART containers A three-step process converts an existing health IT system into a SMART container: exposing data through the SMART API, providing a place for apps within or alongside the existing health IT system’s user interface, and implementing appropriate authentication. In addition to the SMART reference container, we are SMART-enabling three open source systems: the Indivo PCHR15e17; the Informatics for Integrating Biology and the Bedside analytic platformdi2b218 19; and the Open Medical Record System (OpenMRS).20 21 Using published Cerner APIs, we are working to implement a portion of the SMART API on top of the Children’s Hospital J Am Med Inform Assoc 2012;19:597e603. doi:10.1136/amiajnl-2011-000622