Introduction 🔗
Medical device software needs to integrate seamlessly into the clinical workflow to be useful. Clinicians see many patients daily, and they won't use software that requires extra steps like logging into a new app or copying and pasting information.
Some medical devices, like clinical decision support software (CDSS) or precision dosing apps, work best when directly integrated into the EHR.
At Innolitics, we’ve helped several startups integrate their software with EHRs. One effective approach to accomplish this is to use SMART on FHIR.
This article gives a quick overview of SMART on FHIR and helps you decide if it’s right for your technology. If you need a partner to help develop a SMART on FHIR app, reach out to us for a quote on your custom software project.
What is SMART on FHIR? 🔗
SMART stands for Substitutable Medical Applications and Reusable Technologies. SMART on FHIR is an API specification that allows medical applications to integrate consistently and securely. It offers open specifications for interoperability between apps and healthcare systems.
Users of different EHR systems can add, remove, and reuse apps built on SMART on FHIR. This enables seamless switching between multiple apps with a single authorization. Developers can use SMART applications across various healthcare systems without needing custom integrations for each system. SMART on FHIR provides four key areas of functionality:
Launch 🔗
SMART specifies a URL scheme for healthcare systems to launch web-based apps and pass EHR context (patient info, clinical encounter, etc.). It also allows apps to request context from the EHR authorization server when launching outside an EHR session. There are five ways that the standard describes for launching the apps:
| Type | Description |
|---|---|
| Provider EHR Launch | An app launches from within an established EHR session and runs in the context of something like a patient record or user-level app. |
| Patient Portal Launch | A patient opens the app from within a patient portal. |
| Provider Standalone Launch | The app launches from outside an EHR session and the context must be requested from the EHR authorization server. |
| Patient Standalone Launch | A patient launches the app directly and connects to FHIR. |
| Backend Service Launch | A headless or automated client app connects to a FHIR server and can interact with an EHR without a user login process. |
The sequence diagrams presented below illustrate the Provider EHR Launch and the Provider Standalone Launch types. You can also checkout the SMART Launcher app to view how these launch approaches work in detail.
User and Identity Management 🔗
SMART uses a custom OpenID Connect (OIDC) specification for identity management, allowing apps to request access to clinical data. OIDC provides secure identity authentication and allows users to access multiple apps with a single sign-in.
Authorization 🔗
SMART uses the OAuth2 (Open Authorization) protocol to securely request and use authorization to retrieve resources from the EHR. OAuth specifies what data the application can access and what it can do with that data.
Data Access 🔗
SMART on FHIR follows the FHIR standard for data exchange, providing reliable and consistent data access. FHIR defines core healthcare concepts organized into resources (Patient, Encounter, Condition, etc.) and describes an API to exchange these data elements. SMART on FHIR adds specifications to ensure developers know what vocabularies will be used to express clinical data.
Sequence Diagrams 🔗
The following sequence diagrams illustrate how a SMART App integrates with the user and the EHR.
High-Level Limitations 🔗
Integrating SMART on FHIR with existing EHR systems can be complex and resource-intensive, especially with older systems or those not fully compliant with FHIR standards. If an application already integrates with an EHR system using non-FHIR resources (like older versions of HL7), additional customization may be needed to map the data to FHIR resources.
Extending and adapting FHIR resources to specific use cases can be challenging and may complicate interoperability. For example, doctor's notes and medical images require a separate resource type (DocumentReference) to be shared.
Implementing and maintaining SMART on FHIR solutions can be costly and require specialized knowledge. This may necessitate substantial training to ensure data security when working with PHI (protected health information).
Regulatory compliance can also be challenging. Keeping up with changes to the FHIR standard and maintaining compliance with healthcare regulations can be demanding. Noncompliance may result in legal consequences.
When is it a Good Fit? 🔗
SMART on FHIR is a good fit if your application needs to integrate with multiple EHR systems, follow data standards for interoperability, and maintain regulatory compliance.
For example, a medication reconciliation application benefits from SMART on FHIR by allowing clinicians to view and update patients' medication lists. It provides a streamlined workflow to access structured patient data and integrates seamlessly with EHR systems.
SMART on FHIR can accelerate development by allowing developers to focus on functionality rather than complicated custom integrations. Most developers are familiar with restful JSON-based APIs, making it easier to learn and implement these APIs than older messaging-based standards like HL7 V2.
Most healthcare applications must comply with regulations like HIPAA in the U.S., which mandate secure and standardized data exchange. SMART on FHIR ensures compliance with regulations like the ONC’s Cures Act Final Rule, which requires support for modern computing standards and APIs.
When is it Not a Good Fit? 🔗
SMART on FHIR may not be suitable for applications that:
- Are standalone or require integration with legacy systems: Some EHR vendors or healthcare systems may not support SMART on FHIR, causing integration issues.
- Involve highly customized workflows or data formats: Varied data structures in EHR systems could add complexity, requiring more work to map everything to standardized FHIR resources. Certain clinical scenarios and data elements may not be fully covered by existing FHIR resources.
- Require real-time processing and/or low latency: The overhead associated with querying and retrieving FHIR resources in real-time can lead to noticeable latency. Certain applications, like clinical decision support systems (CDSS), require processing large volumes of patient data in real-time to be effective.
These situations may cause delays or increased costs in implementation, so it's important to understand the full context before committing to developing a SMART on FHIR application.
Additional Resources 🔗
- SMART on FHIR Documentation - Official documentation with standards, specifications, tutorials, examples, sandboxes for testing, and support links.
- SMART Example App Launcher - Provides a sandbox where you can explore the various methods of launching SMART on FHIR apps.
- US Core Profiles Implementation Guide - Defines minimum constraints on FHIR resources to create the US Core Profiles.
- Auth0 Blog on SMART on FHIR - Describes the benefits of SMART on FHIR and its potential ubiquity in healthcare systems.
- J2 Interactive on SMART on FHIR - Explains core concepts of SMART on FHIR and the impact of the 21st Century Cures Act and Final Rule.
- Microsoft on OpenID Connect - More details about OIDC and how it works.
- Microsoft on OAuth - More details about OAuth and how it works.
