A Step-by-Step Guide to SMART on FHIR App Development

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.

How does SMART work on FHIR?

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.

Implementing SMART-er steps

The SMART on FHIR collection of open specifications governs the creation of healthcare applications coupled with EHR systems, to give you the quick version of the solution. These specifications enable us to run plug-in applications inside any HIPAA-compliant EHR.

Healthcare apps that are not integrated with other digital solutions, such as clinical support or EHR systems, are less valuable than those that are. Clinics and healthcare service providers truly require the EHR to move freely between medical apps in order to make better use of healthcare data and outcomes. Here is where Fast Healthcare Interoperability Resources, or FHIR, first appears.

For digital products and apps that want to communicate health data, the FHIR standard specifies the type and structure of that data. A non-profit group named HL7, which specializes in developing standards for healthcare data interchange, produced FHIR.

How are SMART and FHIR integrated?

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.

As of right now, SMART on FHIR is a standard and open way for EHR systems, data sources, and medical software to exchange data. A sandbox for testing and an app gallery are available on the SMART side.

SMART PopHealth: Successful SMART on FHIR Implementation

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.

What makes programmers so fond of SMART on FHIR?

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

The list of available apps for patients and clinicians on SMART on FHIR is constantly expanding.
SMART-compliant applications can be reused. For instance, it would take little work to repurpose one app.
You can consult with a broad network of engineers and other technical professionals on SMART on FHIR.
Developers can make their apps better without destroying how healthcare professionals and patients access data. The technology merely disengages the rules for using an app to access EHR.

FHIR alone vs. SMART on FHIR

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.

So, how was it before SMART on FHIR?

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.

How did SMART resolve this?

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.

Many standards have been developed by HL7 and FHIR. It all comes down to resources. Many materials are available in HL7 FHIR. FHIR also comes in R4, R5, and other variants. Each resource has a schema that is defined. These materials can be represented in XML, JSON and other formats by a patient resource. Each of them FHIR resources. Three sections make up it: extensions, narrative, and defined structured data. Therefore, you can enter this information inside the extensions if you wish to incorporate some customized information that isn’t a part of the resource itself.

The data model is merely one aspect of SMART on FHIR. It’s essentially an ecosystem, and within that ecosystem, there is an FHIR server, an authorization server, and a server for EHR data and an application that connects to both of those servers. This EHR ecosystem is supported by numerous EHR companies, including Epic, Cerner, Allscripts, and others.

To skip and learn about the app development process, go to “The interactive launch process”

SMART on FHIR offers a set of APIs, standards, and specifications that make developing and deploying healthcare apps easier and effortless.

Health application development with SMART on FHIR

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.

Best practices for implementing SMART on FHIR

Developers should follow the following guidelines for successful solution development and deployment when integrating SMART on FHIR apps:

Making programmes that are easy to use and intuitive.
Ensuring HIPAA compliance and app security, as well as other healthcare privacy requirements.
Evaluating apps in-depth before releasing them.
Supplying appropriate instructions and user assistance.
Frequent updates to make sure the apps are still adaptable to the changing needs.

The SMART launch sequence

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 is the individual who is actually using the application to carry out a task.
The SMART on FHIR application that the user wants to employ to carry out a particular task.
Web server that is OpenID Connect compliant and able to authenticate users and issue Access Tokens.
Using Access Tokens provided by the Authorization Server, this FHIR-compliant web server can react to FHIR REST queries.

The interactive launch process

STEP 1 (Application Launch)

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 URL that the user will be forwarded to in order to actually log in is the Authorization Endpoint.
The SMART on FHIR Application may communicate with the Token Endpoint in order to exchange data with the Authorization Server.

STEP 2 (Request Access)

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.

STEP 3 (Receive Tokens)

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.

STEP 4 (Client Request to Access or Modify Clinical Data)

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.

STEP 5 (Validate Token)

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:

eyJraWQiOiJ1b.o_GAe_P5E-y4GrCl.gTYd4is8zAQ.

JWT (JSON Web Token) is the name of this format, and libraries for most languages are available to be used to decode this token.

STEP 6 ( Response of the Server to Access or Change Clinical Data)

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:

Conclusion

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.

Get Experts on board for SMART on FHIR Healthcare App Development

Advanced Data ETL, Reporting and Gen AI

No-code data engineering

Automated data transformation

Enterprise-grade LLM

MODULES

Healthcare Data Management

Advanced Data ETL, Reporting and Gen AI

No-code data engineering

Automated data transformation

Enterprise-grade LLM

Solutions that ensure

Advanced Data ETL, Reporting and Gen AI

No-code data engineering

Automated data transformation

Enterprise-grade LLM

Explore more

Advanced Data ETL, Reporting and Gen AI

No-code data engineering

Automated data transformation

Enterprise-grade LLM

A Step-by-Step Guide to SMART on FHIR App Development

How does SMART work on FHIR?

Implementing SMART-er steps

How are SMART and FHIR integrated?

SMART PopHealth: Successful SMART on FHIR Implementation

What makes programmers so fond of SMART on FHIR?

FHIR alone vs. SMART on FHIR

So, how was it before SMART on FHIR?

How did SMART resolve this?

Health application development with SMART on FHIR

Best practices for implementing SMART on FHIR

The SMART launch sequence

The interactive launch process

Conclusion