SMART App Launch: Standalone

As healthcare data becomes more digitized, the need for accessible, interoperable applications that seamlessly access and integrate EHR data is important. The SMART App Launch framework is built on the FHIR standard, which fulfills the need by enabling third-party applications to connect with EHR data securely. Whether launching directly from within an EHR, a personal health record, or a patient portal, the framework provides a unified, secure approach for various users, from clinicians to patients, to access critical health data. 

This framework offers a flexible authorization protocol, supporting several application architectures, including mobile apps running on end-user devices and web-based apps hosted on secure servers. From clinical decision support and data visualization to data collection and case reporting, these applications open new possibilities for more personalized, data-driven healthcare. 

This article will explore how the standalone launch transforms healthcare technology and discuss its implications for patients, providers, and the healthcare ecosystem.

What is a Standalone Launch?

The standalone launch is a feature within the SMART on FHIR framework that allows third-party applications to connect to EHR data independently, without initiating the app from within an existing EHR user session. This standalone launch flow is ideal for applications used by patients or providers outside the direct interface of an EHR system, developing a flexible and user-friendly approach to data access. 

When using a standalone launch, Epic—or another EHR—serves as the Auth0 2.0 identity provider, handling secure user authentication. This setup allows apps to use Epic’s authentication server as a centralized method for verifying user identity, streamlining the integration process across multiple clients. This standardization reduces development complexity, enabling developers to rely on a single Auth0 2.0 authorization framework for various applications, which ultimately helps save time when integrating custom authorization methods for each client. 

Related Read – Guide to Smart EHR Launch for Epic

How does the Standalone Launch Work?

The SMART standalone launch process allows third-party applications to securely access EHR data without being launched directly from within an EHR session. This is particularly useful for applications used independently by patients, providers, or others who need health data access outside the EHR system’s direct user interface. The process leverages Auth0 2.0, a secure authorization protocol, and relies on the EHR authorization server to handle user authentication and grant data access through a token.

Here’s a detailed breakdown of how the SMART launch works: 

A standalone app can be launched independently without needing an EHR or user portal. Unlike the EHR app launch, a standalone app doesn’t require any external platform to initiate its launch. The standalone launch represents the interaction between the patient, the app, the FHIR server, and the authorization server, obtaining access to FHIR resources after the launch. 

1️⃣ User Launches the App

The user launches the third-party application (e.g., a web or mobile app) using a URL with the iss (issuer) query parameter. The iss parameter identifies the FHIR server’s base URL. This step initializes the process and provides the app with the location of the FHIR server that hosts the patient’s health data. 

2️⃣ Third-party App Requests Metadata

The third-party app requests the FHIR servers /.well-known/smart-configuration endpoint (discovered from the iss URL) to fetch the server’s metadata. The metadata provides essential data, including the authorization server endpoint and supported capabilities. 

3️⃣ Discovering the Authorization Server

The app extracts the Authorization Server endpoint from the metadata response. The step identifies the server responsible for managing the OAuth 2.0 authorization process for secure user authentication. 

4️⃣ Authorization Request

The app sends an authorization request to the server. This request includes:

🔸 The launch and user scopes define the app’s context (e.g., access to specific user data).

🔸 Redirect URIs and other client app details.

This request prompts users to log in and approve the third-party app’s access to their health data. 

5️⃣ User Approval and Redirect

Once the user approves the authorization, the server redirects the user to the app’s callback URL (e.g., App/index.html), including an authorization code. The user grants permission, and the app receives a temporary authorization code. 

6️⃣ Authorization Code Exchange

The app exchanges the received authorization code for an access token by requesting the authorization server. The access token is a “key” that allows the app to retrieve data from the FHIR server. 

7️⃣ Access Token Granted

The authorization server verifies the request and issues an access token to the app. This token confirms that the app can access specific FHIR resources for the logged-in patient. 

8️⃣ Accessing FHIR Resources

The app uses the access token to request specific FHIR resources (e.g., user demographics and clinical records) from the FHIR server. This step retrieves the authorized data that the app needs to display or process. 

9️⃣ Data Display

The app processes and displays the retrieved data to the user via the user interface (e.g., in the dashboard or summary page). The final step delivers meaningful, personalized insights to the user based on their health data.

How Do You Register Your Application with Epic for the Standalone Launch?

To enable your application for a standalone launch using Epic’s SMART on FHIR integration, you will need to register it with Epic’s authorization server. This registration process allows Epic to authenticate your app, manage authorization scopes, and control access to its FHIR resources. Here’s a short guide to registering your application with Epic for a standalone launch:

✅ Sign Up for an Epic Developer Account

1. Create an account on Epic’s App Orchard: To begin, you need an account on Epic’s App Orchard. It is Epic’s developer program that provides resources, APIs, and tools to support application development with Epic systems. 
2. Select an Appropriate Plan: App Orchard offers different tiers with varying access levels to Epic’s APIs and tools. Choose a plan that matches your app’s needs, and sign up. 

✅ Submit Your Application Details

Once enrolled in App Orchard, you’ll be required to fill out the details about your app for registration. The details include:

1. App name and description. 
2. Redirect URLs to which Epic will send users after they log in. 
3. Indicate that your app requires standalone launch capabilities. 
4. Specify the type of data and permissions your app will need access to, such as patient-level or provider-level scopes. 

Outline any context requirements for your app to function properly, such as patient ID. Epic will use these requirements to set up appropriate permissions during the authorization process. 

✅ Configure Auth0 2.0 and Redirect URIs

1. Ensure your app is configured to handle the OAuth 2.0 authorization code flow, as Epic’s standalone launch relies on this protocol for secure user authentication.       
2. In your app’s settings, list all redirect URIs that users can be sent after authenticating through Epic’s login page. These URIs must match the ones specified in your App Orchard registration, as Epic will validate them to ensure secure redirection. 

✅ Test Your Application

1. Epic provides a sandbox environment through App Orchard that allows you to test your app’s functionality, including standalone launch capabilities. The Sandbox mimics real-world Epic data and workflows, verifying your app’s authorization flow works accurately. 
2. Test the standalone launch by accessing the app independently and verifying that the OAuth 2.0 flow functions significantly. Confirm that users can log in through Epic’s authorization server and your app receives the correct access tokens and context data. 

✅ Review and Approval by Epic

1. Once your application is ready, submit it for Epic’s review. The review process ensures your app meets Epic’s security, functionality, and data access needs. 
2. Epic may provide feedback or request changes to your app. Address any comments or needs to align with Epic’s standards. 
3. Once approved, your app will be available in production with Epic’s EHR system. 

✅ Deploy Your App in Production

After receiving approval, your app will be authorized for a standalone launch and can be deployed in a live environment. Patients, providers, and other users can use your app independently to securely access Epic EHR data, with all permissions managed through Epic’s authorization server.

How Does Mindbowser Help You with a Standalone App Launch?

Every healthcare solution needs seamless interoperability that empowers patients, improves clinical workflows, and drives quality outcomes. The standalone launch framework provides a solution for applications to securely access EHR data independently, facilitating real-time insights and interactions for patients and providers beyond traditional EHR boundaries. By enabling standalone access through secure authentication and relevant protocols, the EHR expands the capabilities of healthcare applications, bringing the industry closer to a more connected and patient-centered future. 

With Mindbowser’s expertise in EHR integration and healthcare technology, launching your standalone EHR app becomes a streamlined process. We manage the setup complexities, configuration, and compliance, allowing you to focus on creating impactful, user-centered experiences that resonate with both healthcare providers and patients.

User App Launch

A standalone app can be launched independently without needing an EHR or user portal. Unlike the EHR app launch, a standalone app doesn’t require any external platform to initiate its launch. The standalone launch represents the interaction between the patient, the app, the FHIR server, and the authorization server, obtaining access to FHIR resources after the launch. 

👉 User Launches the App

The user launches the third-party application (e.g., a web or mobile app) using a URL with the iss (issuer) query parameter. The iss parameter identifies the FHIR server’s base URL. This step initializes the process and provides the app with the location of the FHIR server that hosts the patient’s health data. 

👉 Third-party App Requests Metadata

The third-party app requests the FHIR servers /.well-known/smart-configuration endpoint (discovered from the iss URL) to fetch the server’s metadata. The metadata provides essential data, including the authorization server endpoint and supported capabilities. 

👉 Discovering Authorization Server

The app extracts the Authorization Server endpoint from the metadata response. The step identifies the server responsible for managing the OAuth 2.0 authorization process for secure user authentication. 

👉 Authorization Request

The app sends an authorization request to the server. This request includes:

🔸 The launch and user scopes define the app’s context (e.g., access to specific user data).

🔸 Redirect URIs and other client app details.

This request prompts users to log in and approve the third-party app’s access to their health data. 

👉 User Approval and Redirect

Once the user approves the authorization, the server redirects the user to the app’s callback URL (e.g., App/index.html), including an authorization code. The user grants permission, and the app receives a temporary authorization code. 

👉 Authorization Code Exchange

The app exchanges the received authorization code for an access token by requesting the authorization server. The access token is a “key” that allows the app to retrieve data from the FHIR server. 

👉 Access Token Granted

The authorization server verifies the request and issues an access token to the app. This token confirms that the app can access specific FHIR resources for the logged-in patient. 

👉 Accessing FHIR Resources

The app uses the access token to request specific FHIR resources (e.g., user demographics and clinical records) from the FHIR server. This step retrieves the authorized data that the app needs to display or process. 

👉 Data Display

The app processes and displays the retrieved data to the user via the user interface (e.g., in the dashboard or summary page). The final step delivers meaningful, personalized insights to the user based on their health data.