SMART

  • ONC-funded, Boston Children’s Hospital-led effort (unlikely to become a certifying body for apps)
  • Project got 15mUSD funding
  • Developed a API which allows a number of existing health IT platforms and EHRs to connect to specially designed HTML5 or iOS apps
  • Showed apps developed by devs - SMART, Cerner, Intermountain, Harris, and Hewlett Packard

SMART is a specification of a platform for medical apps and not a piece of software. The SMART Reference Container is a reference implementation of SMART. It is a self-contained sample EHR that fully implements the SMART specification.

With the SMART API, the context of the physician and patient is available to the app directly from the EHR

SMART stands for Substitutable Medical App,Reusable Technologies.This is a platform for developing substitutable medical apps around reusable technologies.In simple words, SMART app is just a web application developed using HTML and JavaScript  that uses medical record data from EMR through a common API called SMART API. SMART apps use a common API which enables them to run independent of the EMR.


The main focus of the framework is not on cross-vendor integration but on exposing a developer-friendly API to support an ecosystem of substitutable medical applications running across a wide range of EMRs through the SMART abstraction layer.

At the end of the day, being a SMART Container means meeting a set of specifications (responding to the right API calls, mapping data appropriately, handling authentication, and giving apps a place in the system UI. 

As far as the U.S. is concerned, the EHR vendors who are responsible for the majority of installed systems used in in-patient and ambulatory care are focused on Meaningful Use certification and supporting the IHE integration profiles. And they're still using HL7 2.x with no serious plans to evolve any further

SMART's primarily focused on providing a Web API for apps that consume health data and integrate with health IT systems.  As such, we provide:

1.  Data models for clinical summary data
2.  An Resource-oriented API to expose these models on a per-patient basis
3.  An authorization framework (OAuth-based) for delegating access to apps
4.  UI integration so apps can run inside (or alongside) existing health IT systems

We're excited to follow the progress of HL7's FHIR.  You're quite right that FHIR is a resource-oriented approach to health data, with a RESTful API, and (like SMART) FHIR applies an 80/20 approach focusing on defining the data elements that are most commonly found in health IT systems.  So there's a good high-level alignment in modeling goals.  I think FHIR's an excellent step in the right direction -- in terms of licensing as well as modeling paradigm.  

FHIR doesn't directly address #3 and #4 in the list above (but of course those things can be profiled on top of FHIR, and I expect we'll see this happening soon).  SMART has been focused on providing a full-stack solution (UI, auth, models, and API), and we've been iterating on the API since 2010.  We're continuing to track projects in this space (including FHIR and CIMI) -- and we're excited to see more concrete, clinically-motivated data and APIs come online across the board!

 

SMART Reference Container components

The SMART Reference container is a basic EMR system that fully implements the SMART specification. It is written in Python with the Django web framework. The patient medical data is stored in RDF graph form in a triplestore engine (OpenRDF Sesame by default) while the user and app data is in a relational database (Postgres or equivalent). The reference container consists of the following modules:

SMART Server, which implements the SMART API specification and enforces authentication and authorization rules

SMART UI Server, which provides a basic web UI for exploring the patient records with SMART apps

SMART Sample Apps Server, which hosts a collection of sample SMART medicial apps

SMART Sample Patient Generator, which generates a set of sample patients to be used for demonstration purposes


Programming with SMART platform


The Java and Python libraries that you are referring to are only necessary if you need to connect to a SMART container via the REST API (if the app has a back end service that needs SMART connectivity or if the app is a native platform app). In general though, if you are developing a SMART Connect app with no back-end connectivity to SMART (basically an HTML5-based app), then you don't need these clients. In this scenario, all you need is the smart-api-client.js

Goals

The major deliverable of this project will be the SMART platform architecture, which will achieve two major goals:

  • The first will be a user interface that will allow “iPhone-like” substitutability for medical apps based upon shared basic components.
  • The second will be a set of services that enable efficient data capture, storage, and effective data retrieval and analytics, which will be scalable to the national level but nonetheless respectful of institutional autonomy and patient privacy.