SMART on FHIR: a standards-based, interoperable platform for electronic health records

SMART is an acronym for Substitutable Medical Applications and Reusable Technologies (SMART). SMART Health IT is an Open standard based technology platform enable to create apps that integrate with Electronic Health Records (EHR), Health Information Exchanges and other Healthcare IT Systems to facilitate ecosystem with key goal to improve clinical care, research and public health.

With SMART on FHIR, developers can connect the Fast Healthcare Interoperability Resources (FHIR) framework with an API to improve communication between their applications. This will have a great impact on interoperability and enable data exchange not currently feasible with HL7 V2. In the case of EHRs, capturing and transmitting data could be as simple as pressing a button once SMART on FHIR is implemented. SMART is an API—an application programming interface that leverages the emerging FHIR standards to define health data resources: REST web services to transmit the data, and oAUTH for authentication. SMART focuses on three key areas:- SMART focuses on 3 key areas – leveraging other standards to do so. 1. Providing a way for a client to identify themselves and to negotiate access to the data in the EHR. This leverages the OAuth2 standard. 2. Representing the information that is being exchanged, and the manner in which it can be accessed. This uses FHIR Resources (specifically utilizing FHIR profiles for the details) for the content, and the FHIR REST API as the query mechanism. 3. Providing a mechanism by which an external app can be ‘launched’ from an EHR – preserving the context (current patient and user). Client Identification and negotiation access SMART standards have implemented robust OAUTH authorization model for apps that providing a key component that enables innovation while keeping patients and providers in control of their data. Also Read: 6 Ways to Increase sales with Digital Menu Board SMART Genomics and SMART CDS Hooks is taking the lead on defining the next generation of FHIR based standards for the clinical use of genomic data and the integration of  clinical decision support into provider workflows. There are a number of ‘roles’ that are important in understanding SMART (these come from the underlying OAuth2).

• The Resource provider is the supplier of the data – the system that wishes to make the data available via FHIR interfaces to a client

• The Authorization Server is the component that identifies and authorizes both the client and the user wishing to access the data. It can be part of the same application as the Resource Provider – but it doesn’t have to be.
• The App is the actual application that is requesting the information (eg a smartphone app)
• The User is the person who is using the appWhile the implementation details are complex (and can vary from site to site even within the SMART standard) from a high level it’s quite straightforward.A pre-requisite is that the app must be registered with the Authorization Server, which supplies it with an identification key.

When the user uses the app to request some data: 1.    The Authorization Server checks that it knows the app (the app has to supply the key that identifies it). This allows the Authorization Server to customize its behavior based on the capabilities of the app. 2.    The Authorization Server then identifies the user of the app. This can be by requesting a Username/Password, or some other mechanism that the Authorization Server trusts. 3.    Next the Authorization Server determines what data, and what functions on that data (read, insert, update, delete) the user is allowed. Again, the actual details of how that is done varies according to the implementation. This is expressed as the ‘scope’ of the access, and SMART describes how the content of the scope is expressed. One of the possible scopes is for the app to read the user details (name, date of birth, address etc.). Somewhat confusingly, this is also referred to as the user ‘Identity’. 4.    Having identified the user (but only that they are a valid user – not the ‘Identity’ details) and determined what data they can access, the Authorization Server then issues the app with a token (called the Access Token) that the app can then use when requesting the data. 5.    Finally the app makes a FHIR request against the Resource Server, including the Access Token in the request. The Resource Server checks that the token is valid and that the user is allowed to make the request (implementation dependent) and if so, returns the requested data (or processes any updates). Also Read: Impact of Current technology on Mental Healthcare Delivery

• Plug & Play CapabilitiesJosh Mandel, the Chief Architect for SMART says, “The big message about a platform like this is that if you’ve got someone who has a bright idea for a better way to interact with the data in an EHR system, you don’t need to wait for an EHR vendor to adopt that idea, you can build it yourself.”