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 componentsThe 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 platformThe 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 GoalsThe major deliverable of this project will be the SMART platform architecture, which will achieve two major goals:
|