Figure 2 payload. Example of a SMART data Research and applications some containers may need to reshape underlying data to support the SMART API. The container ’s job is best understood through an example. Health IT systems take a variety of approaches to representing medical problems or diagnoses. Some represent a problem as an entity with a start date and a resolution date, persisting over time; other systems represent problems as a series of observa- tions over time. To allow substitutability, SMART takes the stance that a problem has an onset date, resolution date, and a SNOMED CT disorder code. The container must reshape existing data, and the details of transformation will vary case- by-case, but we expect that, in many instances, simple trans- formations can be computed on-the-ﬂy. For example, an EHR may maintain a discrete list of dates and ICD9 codes indicating that a patient experienced migraine headaches. To format the appropriate SMART problem list, the EHR would need to bundle up related ICD9 diagnoses into a SMART problem element with an appropriate onset date, resolution date (which may be for ongoing problems), and a SNOMED CT disorder code for migraine. Figure 2 provides an example. We emphasize that reshaping data in such ways may not always be a straightforward or even well-deﬁned task. Some systems may be unable to implement the complete SMART APIdfor example, if underlying data models are too divergent from the SMART speciﬁcations. Such limitations arise because substitutability is a high bar. Data models, coding, and normalization In practical terms, substitutability is a high bar because it imposes a need for ‘semantic interoperability’ between apps and containers. To achieve this interoperability, SMART deﬁnes a highly normalized abstraction of a medical record that is designed to be intuitive and easy to learn. Key features include: (a) developers work directly with concrete types such as allergy, medication, or problem, not abstract types such as entity, actor, or role; (b) the SMART speciﬁcation is ‘opinionated,’ making upfront choices about how data are represented so that devel- opers know what to expectdfor instance, every problem in a SMART record is associated with a SNOMED CT4 disorder code; (c) SMART deﬁnes a limited set of broadly applicable data types, rather than permitting a proliferation of interface-speciﬁc deﬁnitions. We take this approach because poorly normalized data require developers and apps to expend tremendous effort just ‘making sense’ of the payloads they receive. For example, consider an app that obtains a list of medications from a container to assess for polypharmacy. If some of the medications are coded with National Drug Codes (NDC),5 others with RxNorm6 codes, and still others with codes from a local dictionary, the app must ﬁrst go through the considerable effort of remapping these codes into J Am Med Inform Assoc 2012;19:597e603. doi:10.1136/amiajnl-2011-000622 some common vocabulary, reducing the integrity of the medi- cation list while creating additional work for an app developer. Concretely, SMART represents a medical record as a series of statements or ‘triples’ according to the Resource Description Framework.7 Multiple statements together form a ‘graph’ of patient data. The meaning of each element in this graph is precisely deﬁned by the SMART ontology in OWL2 DL,8 a web standard for representing knowledge based on formal description logics. Thus, each SMART medical record has an explicit, formally deﬁned meaningdbut app developers performing simple operations with SMART medical records do not need any deep understanding of OWL2. Importantly, SMART data models are still a work in progress, and they are limited in scope: the intention is not to provide a detailed model for every possible aspect of a patient’s medical history. Rather, at this stage, SMART attempts to provide highly consistent views for the most common data elements. The SMART data models are freely available.9 App programming interface The current version of the SMART API provides a read-only view of the patient record. An app can access the API through two distinct routes: SMART Connect and SMART REST. SMART Connect is the browser-based JavaScript interface illustrated in the ‘Got Statins?’ app (ﬁgure 1), designed to offer a lightweight approach for developers building apps with rich client-side functionality. SMART REST provides a representation state transfer interface to the medical record, allowing an app’s back- end component to communicate directly with a container. Regardless of whether data are accessed through SMART Connect or SMART REST, the set of API calls and payload formats are the same. Each patient, and each clinical statement about that patient, is represented as a resource with a URI. The structure of these URIs is speciﬁed with respect to a container’s ‘base URI.’ For example, a public SMART sandbox container is hosted with the base URI: http://sandbox-api.smartplatforms. org/. (The user interface associated with this public sandbox is presented at http://sandbox.smartplatforms.org.) An individual patient in the sandbox might be identiﬁed by: <http://sandbox- api.smartplatforms.org/records/123>. A single medication on that patient’s medication list is represented as: <http://sandbox- api.smartplatforms.org/records/123/medications/456>. Authentication and authorization Installing a SMART app on a container is a statement of trust in the app about its functions and handling of privacy and security of data. In this respect, installing a SMART app is no different than installing any other clinical IT system. The SMART archi- tecture is ﬂexible, allowing apps to be hosted within an institu- tional intranet, or remotely ‘in the cloud’. Existing health IT 599