Logical Architecture - Legacy Clinical Systems
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
One way this could be achieved is if each Clinical System vendor was to have an interface that app makers could conform to.
This gives rise to the need for a trust relationship and data model that the app vendor would need to understand.
Consider Scalability
How would this particular model scale? Multiple Clinical System would have different interfaces and app makers would have
to write a logically similar app multiple times. You will also notice that apps are not easily substituted for one another using
this approach
A standard approach
How can we standardized this approach? There is already a need for a Trust Relationship/Security Model and a common
Data model that makes interoperability between the two entities more feasible.
The SMART Standard
This is where the SMART standard comes into play.
SMART - Logical Architecture of Legacy Clinical Systems
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. For more information of the OAuth2.0 specification please visit - https://oauth.net/2/
SMART Application Profiles
SMART supports the idea of confidential and public app profiles. We have seen that as part of the OAuth 2.0 specification the application gets a "client_id" and "client_secret" after it registers with the Clinical System.
| Confidential app Profile | Public app Profile |
|---|---|
Usually run on a trusted server that has some business logic such as PHP, .NET, Java etc | Usually run on end-user mobile devices such as android, iOS, windows etc |
The "client_secret" that they have embedded can be kept secure | The "client_secret" if embedded is prone to being extracted. |
For more information on the types of logical architectures supported by SMART, please see - http://argonautwiki.hl7.org/images/4/4c/Argonaut_UseCasesV1.pdf
Logical Architecture - Legacy Clinical Systems
Some common components of legacy Clinical Systems include
- An application server
- An authorization server
- A database
These components can be part of a single entity or they can be distributed across the network.
In-order to be SMART compliant, the Clinical System will have to have a Trusted Agreement with the application vendor.
The Clinical System will need to server FHIR content and this can be achieved using a FHIR Server or a FHIR Facade that is able to server FHIR content.
The authorization server will need to have the OAuth 2.0 sepcifcaiton implemented and lastly the Clinical System will need to embed an iframe to render the contents of the SMART Application
SMART compliant CapabilityStatement