A common architecture called “Substitutable Medical Applications, Reusable Technologies” or “SMART” makes it easier to create interchangeable medical apps.
The SMART Health IT Project has drawn the collaboration of numerous organizations since it was founded in 2010 (forming the SMART Advisory Committee). SMART is now a standard that operates within the same ecosystem as FHIR. Thus, “SMART on FHIR” was coined.
Without SMART on FHIR, it would be difficult to envisage a medical application that uses electronic health records (EHRs). They do exist, but maintaining them is difficult, and integrating them with some specialized EHR systems is tedious and expensive.
The three pillars of contemporary healthcare are sustainability, interoperability, and security, which explains the significance and appeal of SMART on FHIR today.
As stated earlier, SMART on FHIR is a framework that makes it possible to create safe and functional healthcare applications. This standard operates on any combination of operating systems and underlying processor architecture since it is platform-agnostic.
A set of APIs, standards, and specifications provided by SMART ON FHIR make it simple and easy to design and deploy healthcare apps.
Health care professionals can access and use patient health data thanks to apps made with the SMART on FHIR framework. In turn, this enhances patient care and lowers healthcare expenses.
A new phase in the creation of healthcare solutions began with the introduction of SMART on FHIR. It streamlined the SMART on FHIR connection with EHR and medical software and sped up the engineering process. SMART is based on the FHIR standardized data and simultaneously adds a second layer of authorization.
Let’s look at SMART PopHealth as an illustration of how the SMART on FHIR framework might be used to enhance healthcare services.
In conjunction with Boston Children’s Hospital, the SMART Health IT project team created and released (in December 2020) the SMART on FHIR application known as SMART PopHealth. Leading Edge Acceleration Projects (LEAP) in Health Information Technology had awarded it a $1 million grant.
For clinicians, the app functions as a population health data dashboard. In-depth views of the live data and indicators of the health outcomes for the populations they cover are given to payers and providers.
Data is presented for a two-year window (the current year and the preceding year) on a single page in the form of charts and is gathered from various organizations and sources. This software also includes a data grid to preview the cohort and a full reporting page on quality measure descriptions.
The Office of the National Coordinator for Health Information (ONC) claims that software solutions with the capability to alter how value-based care is perceived and provided, such as apps like SMART PopHealth, are robust solutions to transform healthcare systems.
First off, since data is shared in a known manner, processing data produces fewer faults. Second, the creation of SMART on FHIR apps is sped up by programmers’ use of tangible data items. Tech-wise, SMART on FHIR offers various advantages, including app reuse, a large app gallery, and open standards. Because of this, SMART on FHIR is widely used.
Let’s examine each benefit in more detail
Between FHIR alone and SMART on FHIR, there is a big gap. For instance, permission and authentication are already included in SMART on FHIR. The greatest distinction is that SMART on FHIR supports EHR UI integration, which unifies apps under a single user interface to make switching between apps easier. As an illustration, clinicians can access a few integrated apps through their EHR when they use them.
Supposing we have three EHR vendors: vendors A, B, and C. In addition, a number of apps have been developed on top of these EHR vendors. For instance, Application 1 builds on Vendor A, Application 2 builds on Vendor B, and Application 3 builds on Vendor C. Now as a developer, when Application 1 was built, it adhered to the instructions on how to build the application on that specific EHR vendor, and even though these Applications 1, Application 2, and Application 3 do the same thing, listing and displaying the medications for a single patient, Application 1 is unable to switch to Vendor B; if it wants to switch to Vendor B, the developer must switch to Vendor B and redo the application and follow vendor B’s building instructions; this limits the developer’s ability to innovate.
By placing an additional layer between the EHR vendors and the applications, it addresses this issue. Each EHR vendor must adhere to the SMART framework while creating their SMART container in order to host these systems on top of their EHR systems. The SMART framework describes how to design a SMART container.
The developer in this case adheres to the instructions on how to create the application on top of the SMART container so that it becomes vendor independent. Application 1 uses SMART to route its traffic through the SMART container. This is so that Application 1, Application 2, and Application 3 can all support Vendor A, Vendor B, and Vendor C. If you are a patient utilizing this and you don’t like Application 1, you can switch to Application 2 because it is independent of the EHR vendor.
Since these systems can handle any of these applications and any EHR vendor, it makes no difference when you present that ellipse. You may now change your application. It is called substitutable medical applications for this reason.
Since these systems can handle any of these applications and any EHR vendor, it makes no difference when you present that ellipse. You may change your application. It is called substitutable medical applications for this reason.
SMART on FHIR offers a set of APIs, standards, and specifications that make developing and deploying healthcare apps easier and effortless.
A common choice for delivering health applications a uniform approach to security and data needs is the SMART on FHIR protocol. A workflow for securely requesting access to data, receiving it, and using it is defined by SMART on FHIR. There are numerous examples of SMART on FHIR apps in the SMART App Gallery, and new ones are being developed daily.
SMART on FHIR is basically three things in one package:
The OpenID Connect : This identity management protocol, which SMART employs, enables applications to seek access to clinical data. SMART is built on the OAuth 2.0 standard (authorization protocol implemented by the organization AUTH0) for authenticating and approving users and apps. Thereby, implementing the protocol onto the applications necessitates that it seeks approval before accessing a user’s medical data.
Besides authentication standards, the framework supports encrypted communication over HTTPS, ensuring data is transmitted securely. This helps maintain users’ trust and transparency regarding using relevant data.
Simple read-only access to a small number of records, comprehensive read/write access to a whole EHR, or anything in between could constitute this access. The OpenID Connect is tailored for usage in the health context described in the SMART standards.
Access to Data: To actually read and/or update such data, SMART employs the FHIR standard. FHIR’s data elements help maintain a consistent flow of healthcare data within the framed healthcare ecosystem. While FHIR resources such as predefined operations, viz., read, write, and search, help the app access and manipulate a user’s medical data once it gets approval from the concerned parties.
This indicates that SMART applications can leverage a variety of FHIR services in a SMART on FHIR architecture. Using the Identity and Access Management layer mentioned above, these services are protected.
Launch: For web-based apps, SMART outlines a standardized URL scheme that portals, EHRs, etc. EHRs are the databases that hold sensitive PHI (Protected Health Information). These are provided by parties dealing extensively with securing, managing, and accessing highly confidential data.
For instance, developers can use the APIs to authenticate and authorize users, retrieve patient data, and update EHR records can be used to launch web-based applications while passing the application a set of context parameters. This context may include details about the patient who is now being chosen, a clinical interaction, style details, etc.
Application platforms come in a variety of shapes and sizes, but the most prevalent kind of SMART application currently available in the gallery is web-based. Rich mobile/mHealth applications can be made using the same technology as the SMART on FHIR protocol. Backend processing applications can be made by offering a standardized means of authorizing access to data.
Developers should follow the following guidelines for successful solution development and deployment when integrating SMART on FHIR apps:
Here, OAuth2 and OpenID Connect are the supporting technologies. OAuth2 enables a user to sign in to Application A using their account credentials from Application B without ever requiring or allowing Application A to view or know about those credentials. The application can also ask for “Scopes” as part of the protocol, which are authorizations to carry out particular tasks.
As opposed to OAuth2, the OpenID Connect protocol expands on it by including identity management features, such as the ability for the application to gather user demographic information and other information.
There are four parties involved in the SMART on FHIR Authorization process:
The user often clicks on a link to access web-based applications. The “launch context” is specified by the link’s parameters. Let’s say someone has developed a SMART on FHIR application to visualize a certain lab test’s historical trend. Users would follow a link to this application from within a view that is specific to a particular patient while logged into another system (such an EMR or a clinical portal) as part of the process for this application.
The information about which patient was being viewed would be included in the link to open the SMART on FHIR application. The authorization procedure might not operate in this manner in different architectures (such as mobile applications and standalone web applications).
The SMART Application will retrieve the SMART Discovery Document from the FHIR Server as the first action of the launch sequence. The SMART Application can utilize this brief JSON document to learn more about the FHIR server’s permission needs. It is hosted at a known URL behind the FHIR server.
This endpoint delivers a JSON file that looks something like this:
Two significant URLs can be found in the discovery document:
The user is sent to an OpenID Connect Authorization Server by the application. In general, the SMART on FHIR application never learns the user’s credentials because they are sent to a third-party website where they must be entered (if they aren’t already signed in).
For web applications, this phase typically involves sending the user to the third-party authorization server for a brief period of time after clicking on a link. For mobile applications, a temporary web browser window is opened on the user’s device so they can connect to the authorization server.
A set of “OAuth2 Scopes” are also requested when the SMART on FHIR Application refers the user to the authorization server.
The user is subsequently redirected to the SMART on FHIR application after successfully authenticating with the Authorization Server. The SMART on FHIR application obtains an Access Token as part of this stage. It’s also possible for the Authorization Server to provide an ID Token. This token provides details about the user who is currently logged in. Information may include an FHIR URL to a resource defining the user as well as demographic details like their name and email address.
The Authorization Server may also provide a Refresh Token. When the current access token expires, the Application can utilize this token to request new ones.
By interacting with the Resource Server, the application can now call FHIR services. A SMART on FHIR Resource Server is an FHIR server that accepts an Access Token as part of a request for one or more FHIR operations. The request could be an FHIR create operation to upload newly developed data or an FHIR search activity to find data.
The user’s authority to carry out the specific function they are invoking will be evaluated in light of the scopes that the Authorization Server requested and granted. Here is an example HTTP request. The access token is followed by the string Bearer in the Authorization header, which is present. The token has been condensed to make it easier to read.
Now the Resource Server needs to confirm that the token is legitimate. The Resource Server can confirm that the token is authentic by checking the digital signature that the Authorization Server used to sign it.
A public key that is either provided out-of-band or requested by the Resource Server is used for the verification process. The Authorization Server’s private key and this public key are compatible.
The token will look similar to the following:
JWT (JSON Web Token) is the name of this format, and libraries for most languages are available to be used to decode this token.
The server will now respond to the specified FHIR query if the access token has been appropriately validated and the token introspection demonstrates that the user has the necessary rights to carry out the desired functions.
FHIR query using an access token provided by the Authorization Server is demonstrated in the following example:
The development of a highly interoperable and patient-focused ecosystem will determine the direction of the US healthcare industry in the future. A significant step in the correct way is to implement SMART on FHIR at the appropriate system nodes. You might get assistance from a healthcare interoperability solution professional in this process.
Our healthcare IT team has more than ten years of combined experience working in the US healthcare sector. Keeping your needs in mind, we can assist you with developing SMART on FHIR compatible applications.