SMART on FHIR: Unleashing the Potential of Health Data

The integration of SMART on FHIR technology into healthcare systems has become increasingly critical, with a consensus among healthcare executives highlighting data interoperability as a paramount priority. Recognizing this need, our team has focused on enhancing the capabilities of the Kodjin FHIR Server by implementing SMART on FHIR support. This implementation addresses the challenges presented by the fragmented digital healthcare landscape, facilitating a smoother and more secure exchange of clinical data across different systems.

SMART on FHIR empowers developers to craft and deploy medical applications capable of seamless interaction with health records through a well-defined authorization flow. This flow is meticulously designed to ensure the security of patient data while prioritizing user consent and privacy.

Below, we will explain how SMART works with FHIR, illustrate a SMART on FHIR architecture with the authorization flow example, and talk about the value healthcare organizations gain from leveraging these standards.

What is SMART on FHIR?

SMART on FHIR in healthcare is a set of open standards and specifications that work in conjunction to provide means by which healthcare IT professionals can create and seamlessly integrate healthcare apps. 

SMART on FHIR framework stands for and combines:

• FHIR (Fast Healthcare Interoperability Resource) is an open specification developed by the HL7 that standardizes how healthcare information is represented, stored, and exchanged between different clinical data systems. To gain a comprehensive understanding of this standard and its significance in healthcare, it’s beneficial to explore what is FHIR.
• The SMART (Substitutable Medical Applications and Reusable Technologies) platform standardizes authorization and authentication to enable third-party applications to connect to healthcare systems (primarily EHRs). SMART was born to enable “interchangeable healthcare applications,” meaning any developer could create a healthcare app that would integrate and work with any healthcare organization. The aim was to make it especially easy for providers to try out different solutions and find the one that fits their needs best. The platform acts as a security layer built on top of FHIR-based systems.

Together, SMART on FHIR offers a robust and flexible framework for developers and healthcare providers. It enables the development of apps that can be easily integrated into existing healthcare systems.

“The goal of SMART is audacious and can be expressed concisely: an innovative app developer can write an app once, and expect that it will run anywhere in the healthcare system,” said Kenneth D. Mandl, MD, MPH Chair of the SMART Advisory Committee

Some of the SMART on FHIR applications:

• Access to a standardized format of patient data.
• Improved patient engagement through personalized apps.
• Enhanced data analytics and decision support tools.
• Streamlined clinical workflows.
• Increased interoperability among different health IT systems.

The SMART on FHIR framework is increasingly becoming a key component in modern healthcare informatics, promoting better health data exchange and utilization.

How does SMART on FHIR architecture work?

To best understand how SMART on FHIR works and its many advantages, we’ll describe the authorization process that SMART-compliant FHIR servers adhere to.

SMART on FHIR architecture implements the OAuth2.0 with OpenID Connect, a widely-used authorization and identity management protocol. It’s familiar to many users, as the same protocol allows you to use «Login with Google» or «Login with Facebook» on various websites or applications. In the context of SMART on FHIR in healthcare, however, the role of Google or Facebook as the authorization server is taken by SMART-compliant authorization servers such as Keycloak or Okta, for example.

To describe the authorization flow, let’s say there’s a mobile app that wants to access patient information to display a historical heart rate graph. When a user installs this app and wants to sign up, they are redirected to the authorization server with a login screen that asks them to approve the necessary permissions called scopes.

SMART on FHIR scopes are used to delegate specific access rights to third-party applications. There are patient-specific, user-specific, and system-specific level scopes that can be granted various permissions such as .read, .write, and .* (SMART on FHIR version 1.0.0)  or *.cruds (SMART on FHIR version 2.0.0).

(It’s important to note that scopes are app permissions, meaning a user might have write permissions, but if the app does not, it cannot write any data on the user’s behalf.)

If the login is successful, the authorization server provides a temporary authorization token that can be used by the mobile app to request an access token. The access token is an encrypted and digitally signed piece of information containing crucial information in an FHIR-compliant format, such as who the token was issued by, its expiration date, scope, etc.

The mobile FHIR app sends the access token to the FHIR server, which then validates it through the authorization server. If the operation is successful, the app is granted permission to read the requested information and display it to the user.

The following diagram demonstrates the necessary steps in the SMART on FHIR authorization process:

The authorization process we described also involves user authorization, but it’s not always necessary for SMART apps to involve a user in the access permission process. It’s also possible to set up non-interactive user processes. However, the main principles of SMART on FHIR remain the same.

The Benefits of Smart on FHIR Protocols

Now that we’ve learned what the SMART on FHIR framework is and how it works, let’s talk about the advantages it brings to hospitals, clinicians, healthcare developers, and patients:

• Streamlined Development: SMART on FHIR considerably reduces the costs and time of new app development and integrations. Developers can better focus on building useful applications instead of being preoccupied with implementations since instead of developing new software for EHR systems, users or implementers can choose from a catalog of published solutions and use them in their solution. These can be all kinds of clinical calculators, for example.
• Secure and Efficient Data Sharing: Thanks to the SMART authorization and authentication flows, sharing data between various healthcare systems and applications can be done in a fast and secure manner. The standard oAuth 2.0 protocol as implemented by OIDC brings to FHIR a technology widely used in the web application industry. This means that system developers and integrators do not need to develop customized or proprietary tools to ensure secure connections when solving EHR interoperability issues. That is why SMART on FHIR authentication is considered the best in this regard.
• Simplified EHR Integration: Electronic Health Record (EHR) systems are central to modern healthcare, facilitating the management and exchange of patient information. However, integrating different EHR systems or adding new functionalities often presents significant challenges, including compatibility issues, complex data formats, and stringent security requirements. SMART on FHIR addresses these issues head-on, simplifying the integration process and enhancing the ability to share healthcare data across varied systems.
• Enabling Substitutability: The main idea behind SMART on FHIR integration is to provide “substitutability,” as such EHR systems can phase out legacy applications that have become obsolete without losing any underlying data.
• Enhanced Patient Care: Since SMART on FHIR standardized the implementation of apps, clinicians have a better choice of applications available to them that support administrative and clinical workflow instead of being limited by implementation costs and time. This allows them to provide better care. Patients also benefit from this, as their entire medical history can be made available just a couple of clicks away.

SMART on FHIR 2: What’s new?

FHIR specification is constantly updated and improved. The second version of SMART on FHIR introduces enhanced capabilities aimed at making interoperability in healthcare data exchange even more efficient. These updates allow for more granular data access permissions, facilitate complex search capabilities, and support additional visual customization, all of which contribute to a more streamlined approach in healthcare applications. We will examine these new features below.

Implicit Search Parameters

In a traditional SMART on FHIR implementation, scopes are used to define the level of access an application has to FHIR resources. For instance, a scope might specify that an app can “read” patient data but not “write” to it. These scopes follow authorization protocols and provide granular control over which FHIR resources (e.g., Patient, Observation, Encounter) an app can access.

For example, a scope might look like this:

patient/Observation.read

This scope grants read-only access to Observation resources related to a specified patient. Such scopes are explicit, predefined, and straightforward but have limited flexibility.

FHIR’s search capabilities introduce a logical differentiation in search parameters, particularly as seen in regulatory frameworks like the US Core IG > 6.x, where categories are designated for resources like Observation and Condition. This specification allows search within specific parameter scopes defined by legislation to accommodate nuanced categories within resources.

For example, for the Condition resource, the legislatively defined scopes include:

• patient/Condition.rs
• patient/Condition.rs?category=http://hl7.org/fhir/us/core/CodeSystem/condition-category|health-concern
• patient/Condition.rs?category=http://terminology.hl7.org/CodeSystem/condition-category|encounter-diagnosis
• patient/Condition.rs?category=http://terminology.hl7.org/CodeSystem/condition-category|problem-list-item

For Observation, this structure includes the following category-level specifications:

• patient/Observation.rs?category=http://hl7.org/fhir/us/core/CodeSystem/us-core-category|sdoh
• patient/Observation.rs?category=http://terminology.hl7.org/CodeSystem/observation-category|social-history
• patient/Observation.rs?category=http://terminology.hl7.org/CodeSystem/observation-category|vital-signs

However, adding complex FHIR search structures, like chaining parameters across resources (e.g., querying Observation based on related Patient data), may create scenarios incompatible with OAuth 2.0 and OIDC constraints. As a result, certain functionalities remain in an experimental status.

This differentiation highlights the regulatory-driven need for distinct scopes, while the scope structure in FHIR, especially within legislated contexts, provides controlled flexibility for searches within specified categories.

Implementing search parameter chaining presents unique challenges for FHIR servers. Search parameter chaining allows one resource (e.g., Observation) to be queried based on attributes of a related resource (e.g., Patient’s birthdate). While this feature is powerful for building sophisticated queries, it introduces several challenges for servers:

1. Performance Impact: Chained searches require servers to traverse relationships between resources, which can be resource-intensive. In the above example, the server would first need to identify all patients born in 1990 and then retrieve their related observations. This adds additional query complexity, which can impact server performance, especially in systems with large datasets.
2. Consistency: Supporting complex search parameter chaining consistently is difficult. FHIR servers need to ensure that the relationships between resources are well-structured and indexed for efficient querying. If these relationships are not properly managed, the server may return incomplete or incorrect results.
3. Indexing Requirements: To support search parameter chaining efficiently, FHIR servers need to implement sophisticated indexing strategies. Without proper indexing, chained searches can become prohibitively slow, as the server has to scan multiple resources and relationships to fulfill the query.

Enhanced OAuth 2.0 Capabilities

Security remains a cornerstone of SMART on FHIR, and version 2 builds on the existing OAuth 2.0 framework. This update introduces more granular scopes and permissions for access control. Developers can now define permissions with greater precision, specifying exactly what level of access is required for different types of data. The enhancement ensures applications only access the minimum necessary data, improving security and compliance with data privacy regulations, such as HIPAA in the US or GDPR in the European Union.

For healthcare organizations, this translates into more control over how their data is accessed and shared by third-party apps. For developers, it provides a flexible yet secure way to implement authentication and authorization workflows.

SMART on FHIR also improves the developer experience by introducing updated launch context parameters and enhancing documentation.

Updated Launch Context Parameters

Launch context parameters allow applications to receive specific information during the initial authentication and authorization process. SMART on FHIR adds new parameters, such as additional patient and encounter context data. 

These parameters are included in the access_token. Some of the key parameters introduced in SMART on FHIR include:

These parameters help applications tailor their behavior based on the context in which they are launched. For instance, if a patient is already selected in the EHR system, the app can retrieve patient-specific data right away, reducing friction in the user experience.

FHIRContext (Experimental)

SMART on FHIR also introduces FHIRContext, an experimental feature that extends the launch context parameters by embedding or referencing specific FHIR resources directly within the launch context. FHIRContext is designed to give applications even more granular, resource-specific data at the time of launch, allowing the app to work with specific FHIR resources immediately.

For example, an app might be launched with specific medication lists for a patient, providing both home and hospital medication records. The app can use this context to present relevant data without needing to issue additional queries.

FHIRContext Example:

{
  "patient": "123",
  "fhirContext": [{
	"reference": "List/123",
	"role": "https://example.org/med-list-at-home"
  }, {
	"reference": "List/456",
	"role": "https://example.org/med-list-at-hospital"
  }]
}

In this example:

• The app is launched with a patient context (“patient”: “123”).
• Additionally, the FHIRContext provides two List resources:
  • List/123, representing the patient’s medication list for home use.
  • List/456, representing the patient’s medication list for hospital use.
• The role attribute (“https://example.org/med-list-at-home” and “https://example.org/med-list-at-hospital”) provides context about the specific use case for each list, guiding the app in how to handle and present these resources.

This structure allows the app to display or interact with the patient’s medication lists without needing to perform separate searches to gather this data. By receiving these references as part of the launch context, the app can improve its performance and provide immediate value to the user.

However, because FHIRContext requires FHIR servers to efficiently support complex queries and provide specific resources at launch, it is still considered experimental and may not be supported by all FHIR servers. The feature is designed to streamline app functionality by reducing the need for subsequent resource queries but poses challenges with server performance and consistency.

Improved Documentation and Examples

With enhanced documentation and more practical examples, SMART on FHIR helps developers understand and implement the framework more effectively. These improvements reduce the learning curve for developers new to the FHIR ecosystem and allow experienced developers to adopt best practices more quickly.

The documentation includes expanded use cases and clearer explanations of how to implement features like OAuth 2.0, implicit search, and app state persistence, making it easier to build and deploy applications.

App State Persistence

One of the new features introduced in SMART on FHIR is App State Persistence. This feature allows applications to retain their state across sessions, making it possible for users to resume interactions without losing context or data. For example, if a user closes the application mid-session, they can return to where they left off when they reopen the app without needing to re-enter information or restart workflows.

For developers, app state persistence reduces the complexity of managing session data manually. It also enhances the end-user experience, particularly for healthcare providers who may need to switch between applications multiple times during a clinical workflow.

Visual Customization and Branding

SMART on FHIR introduces new capabilities for visual customization, allowing organizations to brand the user-facing elements of their applications. This feature is especially useful for healthcare organizations and application developers who want to maintain a consistent brand experience across their digital products.

Let’s explore this new feature and its implications below.

What is the Branding Feature?

The branding feature allows developers to customize the visual aspects of the authentication and authorization screens that are part of the SMART on FHIR workflow. These screens typically include:

• Login screens: Where users authenticate themselves.
• Authorization consent screens: Where users grant permissions to the application to access specific health data.

In previous versions, the visual appearance of these screens was standardized and did not offer much room for customization. With the introduction of the branding feature in version 2.2, organizations can now apply their brand identity to these screens, ensuring that the user experience aligns with their overall visual and brand strategy.

Key Components of the Branding Feature

The branding feature includes several customizable elements:

Benefits of the SMART on FHIR Branding

The branding feature offers several key benefits:

Use Cases of SMART

The SMART on FHIR framework enables a wide range of use cases, each designed to enhance different aspects of healthcare delivery and patient care. From supporting clinicians with advanced decision-making tools to empowering patients with access to their own health data, the applications of SMART extend across the healthcare continuum. Here’s a closer look at some of the key areas where SMART is making an impact:

• Clinical Decision Support: SMART on FHIR applications can provide real-time, evidence-based recommendations to clinicians within their workflow, helping improve the quality of care and patient outcomes.
• Patient Engagement and Education: By accessing their health records through patient-facing apps, individuals can better understand and manage their health conditions, leading to increased patient engagement and satisfaction.
• Population Health Management: SMART on FHIR applications can analyze data across a patient population to identify trends, risk factors, and opportunities for preventive care, supporting efforts to improve public health outcomes.
• Research and Data Analysis: Researchers can use apps to access large datasets for analysis, facilitating medical research and the development of new treatments and interventions.
• Telehealth and Remote Monitoring: Enables the development of apps that support remote care delivery and patient monitoring, expanding access to healthcare services and reducing the need for in-person visits.
• Personalized Medicine: By integrating genomic data and other personalized health information, apps can support tailored treatment plans that are optimized for individual patient characteristics.

What about SMART on FHIR app development?

SMART on FHIR offers a range of benefits to software developers in the healthcare industry. Typically when a healthcare organization wants to integrate another application to extend their EHR system capabilities, a lot of time and money need to be spent on custom development. But with SMART on FHIR support, which offers standardized plug-and-play connections, EHR can work seamlessly with any app built with SMART. This significantly reduces the time and costs of integrating third-party apps with EHR systems.

Furthermore, SMART decouples the protocols for accessing EHRs from a piece of software itself. This means that healthcare IT developers can improve their products and services without worrying about how it will impact the way patients and providers access their data. As a result, this ensures a faster development of healthcare applications, which further improves the quality of the entire marketplace.

SMART also simplifies app development by eliminating the need to build custom connections to each EHR database. Developers can now develop their apps once using SMART, and those apps will work with any EHR databases built with SMART. This broadens the reach of their SMART on FHIR applications to a wider audience of health organizations and consumers, making them more useful and beneficial.

Overall, SMART on FHIR applications provides a standardized platform for accessing and exchanging patient health data.

Popular SMART on FHIR apps

There are many SMART on FHIR apps available that are used by healthcare providers, patients, and researchers. Here are some popular examples:

Growth Chart

A collaboration between SMART, Fjord service design consultancy, Interopion software development group, and clinicians resulted in the development of the Growth Chart app. This app features a streamlined, high-performance interface that presents a child’s growth over time with minimal clicks required.

The data in the app can be represented in three ways: charts, tables, and the Parental View, which is designed for individuals without extensive medical knowledge, such as parents of the child.

The charts view is the most intricate, offering a unique set of features:

• It can display multiple charts in an organized manner, regardless of the data type.
• It includes time navigation and zoom capabilities, allowing users to explore different segments of the data.
• It can display three types of data simultaneously, including patient measurements and up to two additional datasets, enabling comparison to statistical averages.
• It features an interactive selection function, enabling users to click on the canvas to select a point in time and view details of records near that time. Users can also compare other points with the current selection by moving the mouse over them.

CommonHealth

Another example of SMART on FHIR applications is the Commons Project, a nonprofit public trust committed to protecting privacy developed the CommonHealth app. This platform enables individuals to collect and manage their personal health data and share it with trusted health services, organizations, and apps.

CommonHealth supports digital vaccine records in the form of SMART Health Cards, and is linked to over 700 data sources (including reputable healthcare institutions such as Mayo Clinic, Cleveland Clinic, and New York-Presbyterian). Once a healthcare provider is connected to CommonHealth, users can opt to share their health records and data with apps and services verified by CommonHealth for security and reliability.

CommonHealth provides users with several key benefits:

• Convenient access to health information: With CommonHealth, users can access their health information anytime, anywhere, and share it with trusted individuals.
• Comprehensive health information management: Users can import health data from multiple providers and gain a holistic view of their health information. CommonHealth helps patients and the care team understand the patient’s health better.
• Data privacy and control: Users are in charge of their data with CommonHealth. Personal data is stored solely on the user’s device, not in the cloud. CommonHealth does not sell, use, or share your data for marketing or advertising purposes without consent.

Cardiac Risk

The SMART Cardiac Risk app is a tool designed to simplify the calculation and reporting of the widely-used Reynolds Risk Score. With its intuitive and patient-friendly interface, this app presents relevant patient vitals and lab measurements, along with the calculated Reynolds Risk Score and a succinct, easy-to-understand explanation of each result.

The SMART Cardiac Risk app also offers simulation capabilities, allowing clinicians or patients to make changes to one or more of the patient’s vitals or lab results to see how their current Reynolds Risk Score could be improved.

What is the Future of SMART on FHIR?

The future of SMART on FHIR in healthcare is well established. The SMART team has successfully lobbied for language in the 21st Century Cures Act that requires a universal API for health information technology, providing access to all elements of a patient’s record with no special effort. Now for ONC-certified health IT, SMART’s API is now a requirement, and health systems that accept Medicare or Medicaid must also adopt SMART.

In addition, the SMART ecosystem is continually expanding with the development of new projects. CDS Hooks, launched in 2015, allows for third-party decision support services to be triggered. The Sandbox, federally funded in 2016, provides de-identified data to support app development and demonstration.

The team has also designed a standard and suite of tools for the export of large population datasets from electronic health record systems – SMART Flat FHIR/Bulk Data Export.

Moreover, SMART Markers, a standards-based software framework for creating health system-integrated apps for patient-generated health data, is encapsulating the functionality needed for rapid deployment of both patient- and practitioner-facing PGHD apps.

Overall, the continued development and adoption of SMART on FHIR in healthcare bodes well for increased interoperability, improved patient outcomes, and a more efficient and effective healthcare system.

Takeaway

The integration of SMART on FHIR is essential for modern healthcare organizations seeking enhanced data interoperability and streamlined patient care processes. The success of SMART on FHIR in facilitating healthcare interoperability is largely due to the robust and flexible HL7 FHIR Data Model, which standardizes data sharing across systems and applications.

Our Kodjin FHIR server excels in offering convenience and ease-of-use for integrating SMART on FHIR applications. With our specialized FHIR development services, we provide a straightforward path for healthcare organizations to leverage the power of FHIR standards, ensuring seamless data exchange and improved clinical decision-making.

Kodjin’s out-of-the-box support for SMART-on-FHIR allows you to integrate any apps necessary, enabling your organization to focus on what matters most – delivering exceptional patient care instead of development.

FAQ

What is Smart on FHIR?

Smart on FHIR is a technology that enables seamless communication, bulk data export and data exchange between healthcare systems.

How does Smart on FHIR facilitate healthcare interoperability?

Smart on FHIR provides a standard framework for applications to access and exchange health information in a secure and efficient manner, thereby improving healthcare interoperability.

What types of healthcare organizations can benefit from Smart on FHIR?

Smart on FHIR can benefit a wide range of healthcare organizations, including hospitals, clinics, research institutions, and health IT companies.

Is Smart on FHIR widely adopted in the healthcare industry?

Yes, Smart on FHIR is gaining traction in the healthcare industry and is being adopted by healthcare organizations and health IT vendors worldwide.

Post author

Andrii Krylov

Product owner in Healthcare & Life Sciences