Research and applications across multiple systems, including EHRs, PCHRs, and health information exchanges. The SMART Platforms project is funded by the Ofﬁce of the National Coordinator for Health Informa- tion Technology as a part of the Strategic Health IT Advanced Research Projects (SHARP) Program.2 Here we report on chal- lenges and successes faced during the ﬁrst year of the project, and describe the architecture of the system. MATERIALS AND METHODS We present a ﬁctional scenario to convey the need for SMART Platforms. A companydMedtasticdhas designed an elegant medications- management app which needs access to a current medications list from the EHR. While the user-interface design is considered exemplary, and it market tests extraordinarily well with end users, the company ﬁnds that the necessity of having a long and involved sales cycle at each possible install location is draining their venture capital funds. They had hoped to exercise the 80:20 rule and focus on integration with the top ﬁve vendors, but: (1) only two of those are willing to entertain the proposition; (2) the technical teams of those vendors are not enthusiastic about prioritizing the work; (3) the Medtastic technical team has found that there is such variation across different instances of each brand of EHRdbecause of versioning and extensive local customizationdthat installation of their app will not be turnkey in any way. The ﬁrst year of the SMART Platforms project has focused on deﬁning an API that would enable a company like Medtastic to succeed by providing apps with a common interface for working with health data. The interface must be a simpliﬁed and semantically precise abstraction of a medical record with well- structured, normalized data elements that app developers can understand. The approach is to harness standards and technol- Figure 1 ‘Got Statins?’ is a complete SMART application (app) in 50 lines of HTML and JavaScript. The app includes an external SMART JavaScript library, then makes a call to obtain all medications for the in-context patient record. A list of drug names is created, and a loop checks each drug name against a list of known statin drugs. ‘Got Statins?’ is designed merely to illustrate the SMART API. A more robust approach would incorporate drug class data from a reference source such as NDF-RT.3 ogies behind successful web APIs and to employ open standards and speciﬁcations wherever possible. SMART provides speciﬁcations allowing apps to run against existing health IT systems. Our intent is to specify, in detail, everything app developers need in order to create apps rapidly and independently of the SMART team. The scope of the speciﬁcation encompasses user-interface integration, authenti- cation, authorization, API access, and data payloads. Deﬁnitions We deﬁne ‘SMART containers’ as health IT systems, such as EHRs, PCHRs, and health information exchanges, that have implemented the SMART API or a portion of it. Containers marshal ‘data sources’ and present them consistently across the SMART API. ‘SMART applications’ consume the API and are substitutable. Developer focus The SMART architecture aims to reduce barriers that app developers face in building apps on health IT systems. By leveraging web standards, presenting predictable data payloads, and abstracting away many details of enterprise health IT systems, SMART allows app developers to focus on core tasks. In ﬁgure 1, a sample app called ‘Got Statins?’ illustrates the point. ‘Got Statins?’ is a complete ‘hello world’-style SMART app that obtains a patient’s medication list, iterates through each entry, and makes a simple determination. The entire app ﬁts in 50 lines of HTML and JavaScript. Containers Any SMART container must present normalized clinical data to SMART apps in a reliable and consistent fashion, abstracting away details of the underlying health IT infrastructure. Thus, the same app could run inside our public reference container, an EHR, a PCHR, or a health information exchange. To enable such substitutability, the SMART architecture imposes a substantial burden of normalization on any container, allowing apps to know upfront what data to expect and what each data element means. An important implication is that 598 J Am Med Inform Assoc 2012;19:597e603. doi:10.1136/amiajnl-2011-000622