What if, in the midst of a crisis, the CDC could distribute a SMART app to emergency departments as easily as a software developer submits an app to the Apple App Store?
SMART Platform (www.smartplatforms.org) is a project that lays the groundwork for a more flexible approach to sourcing health information technology tools. Like Apple and Android’s app stores, SMART creates the means for developers to create and for health systems and providers to easily deploy third-party applications in tandem with their existing electronic health record, data warehouse, or health information exchange platforms.
To deploy SMART-enabled applications, health systems must ensure that their existing health information technology infrastructure supports the SMART on FHIR API. The SMART on FHIR starter set detailed below lists the minimum requirements for supporting the API and SMART-enabled applications. You may wish to augment this list of minimum requirements with suggestions from the Add-On Functionality listed depending on the types of applications your organization wishes to deploy.
This document is intended as a resource for providers and health systems as they draft Request for Proposals (RFPs) and negotiate with their HIS vendors for added functionality. It has multiple authors from across the SMART team and its advisors. Feedback is welcome.
SMART on FHIR Starter Set
The vendor must support the SMART on FHIR platform, a vendor agnostic API that allows third-party developers to build external apps and services that integrate with the vended product.
At a minimum, the vendor product should include the following components in order to support SMART on FHIR and SMART-enabled applications:
Standards-Based App Authorization
The provider organization may also want to consider the following additions to its RFP depending on the types of applications it wishes to develop and run in the future.
Standards-based App Registration
Context-Specific Service Hooks
The IP of any app integrated through the SMART on FHIR API belongs to the author and not the vendor.
Custom SMART on FHIR Extension to a Proprietary API
Should a vendor neglect to provide SMART on FHIR natively, the client has the right to provide a custom extension to the vendor’s API. The ownership of the IP for the custom extension is negotiable between the client and the vendor, but the ownership of the app using the custom extension belongs to its author.
David Kreda, SMART Translation Advisor
Joshua Mandel, SMART Lead Architect
Some readers of our JAMIA paper “Are Meaningful Use Stage 2 certified EHRs ready for Interoperability?” have wondered if we were insinuating that C-CDAs are all but useless because of their heterogeneity and other defects.
We did not say that.
Apple may have just tightened privacy requirements for developers who build apps on its HealthKit platform. But a broad assessment of the industry, published online last week in JAMIA, found that the iTunes and Google Play stores have a long way to go before such policies are readily discoverable and digestible to app users.
Nuviun Blog, June 9, 2014 — Sue Montgomery
In the midst of the struggles that we face with interoperability, efforts that support open API use may well hold the keys to the HIT Kingdom…
READ MORE >
Today Forbes published Who’s Who Of Health Care Join Forces For SMART Technology, the latest in recent news coverage of the SMART Advisory Committee launch.
Other pieces include: