What is SMART on FHIR®?
It is a technology platform consisting of open standards that allows Clinical Systems (eg: EMR) to integrate and run external applications that enhance the realization and visualization of the in-house data in a secure and unified fashion; thus enabling patients, doctors and healthcare providers to improve clinical care and overall public health.
Leveraging SMART, allows Clinical Systems and application vendors to be compatible and re-usable by reducing the cost and complexity of the integration between the app and the Clinical System. Clinical Systems can therefore add new capabilities and functionalities without having the to adhere to rigorous change request process.
Business case
Concept of an EMR
A Clinical System (Ex: an EMR) acts a ware house for large volumes of health data and is capable of interpreting presenting this
information. However, in some cases it may not have the capabilities to interpret all the data that it has. A change to the system
would often require significant user-interface and various back-end changes to accomodate any new features.
Adding Specialty Capabilities
If there was a way for Clinical Systems to tap an external market of specialty applications, what would this approach look like?
Collaboration Paradigm
Consider Scalability
A standard approach
The SMART Standard
SMART - Logical Architecture
The SMART open standard consists of 3 basic components that enable a Clinical System and SMART Application to interact with one another.
- The need for a Service Level Agreement (SLA) that establishes a trust relationship between the Clinical System and App Vendor
- A security model that is realized using the OAuth 2.0 specification
- A standard data model realized using FHIR and a common profiled baseline
When the concept of SMART was being ruminated by it's innovators, it was originally called SMART classic and had it's own data model which was described using the Resource Description Framework. As FHIR® was gaining in popularity and traction, the innovators decided to switch to the FHIR data model.
Establishing a Trust Relationship
As part of the OAuth 2.0 specification, a new application must be registered win the service (Ex: Clinical System) that requires it's integration. Registration includes basic information such as the application name, website, logo and in addition, a re-direct and launch URL.
I exchange for this, the service will provide the application a "client_id" and "client_secret" which will help identify the authenticity of the the application during the registration process. This "client_secret" must be kept confidential. In case the application (such as a single page javascript app, android app etc.) cannot keep this confidential, the "client_secret" must not be used and a secret must not be issued to the application in the first place.