SMART on FHIR

What is SMART on FHIR?

SMART on FHIR is a set of specifications that enable apps to integrate securely with electronic health record (EHR) systems. Think of it as the "login with Google" for healthcare - it lets third-party applications access patient data from any EHR that supports the standard, without requiring custom integration for each vendor.

The name stands for "Substitutable Medical Applications, Reusable Technologies" on FHIR. That's a mouthful, but the concept is straightforward: build your app once using SMART on FHIR, and it can connect to any compatible EHR. No need to create separate versions for Epic, Cerner, or Allscripts.

The Problem SMART Solves

Before SMART on FHIR, getting an app to work with an EHR required custom development. Each EHR vendor had proprietary APIs and authentication mechanisms. Want your clinical decision support tool to work with three different EHRs? Build and maintain three separate integrations.

This fragmentation stifled innovation. Developers couldn't afford to support multiple EHRs. Hospitals couldn't easily try new apps because integration was expensive. Patients couldn't use health apps that pulled data from their doctor's system because those apps simply didn't exist.

SMART on FHIR changes this by providing a standard way for apps to:

• Authenticate users (prove they are who they claim to be)
• Request permission to access specific data
• Retrieve that data via FHIR APIs
• Launch directly from within the EHR interface

How SMART on FHIR Works

OAuth 2.0 Foundation

SMART on FHIR builds on OAuth 2.0, the same authorization framework used by Google, Facebook, and most web services you use daily. If you've ever clicked "Login with Google" on a website, you've used OAuth.

OAuth separates authentication (proving identity) from authorization (granting permission). This means:

• Apps never see user passwords
• Users can grant limited access (only lab results, not medications)
• Permissions can be revoked without changing passwords
• The EHR remains in control of data access

The Authorization Flow

Here's what happens when a SMART app requests access:

1. User launches app: Either from within the EHR or as a standalone app
2. App requests authorization: Sends user to EHR login page with specific permissions needed
3. User authenticates: Logs into the EHR (or already logged in)
4. User grants permission: Sees what data the app wants, approves or denies
5. EHR returns authorization code: Redirects back to app with a temporary code
6. App exchanges code for tokens: Uses code to get access token from EHR
7. App accesses data: Uses access token to call FHIR APIs

This flow ensures the app never sees login credentials. The access token can be scoped to specific data and has an expiration time. If the token is compromised, revoking it doesn't affect the user's main account.

Launch Contexts

SMART apps can launch in different contexts, each providing different information:

EHR Launch

The app launches from within the EHR interface. The clinician is already logged in and has a patient chart open. The EHR tells the app:

• Which user is logged in (context: practitioner)
• Which patient's chart is open (context: patient)
• What encounter is active (context: encounter)

Example: A doctor opens a patient chart and clicks a "Risk Calculator" app. The app automatically knows which patient to calculate risk for because the EHR provided that context.

Standalone Launch

The app starts independently, not from within an EHR. Common for patient-facing apps or when clinicians access tools outside their EHR workflow.

Example: A patient opens their health tracking app on their phone. The app asks which EHR to connect to, the patient logs in and grants permission, then the app retrieves their data.

Backend Services

For automated processes without user interaction. A system authenticates directly using client credentials, not requiring a human to log in each time.

Example: A research database that nightly pulls de-identified data from multiple EHRs for population health analysis.

SMART Scopes

Scopes define what data an app can access. SMART uses a standardized format:

• patient/Patient.read - Read patient demographics for the current patient
• patient/Observation.read - Read lab results and vital signs for the current patient
• patient/MedicationRequest.read - Read medication orders for the current patient
• user/Practitioner.read - Read information about the logged-in clinician
• patient/*.read - Read all available resources for the current patient

The pattern is [context]/[resource].[permission]:

• Context: patient, user, or system
• Resource: The FHIR resource type (Patient, Observation, etc.)
• Permission: read, write, or * (all)

Apps request the minimal scopes needed. Want to display lab results? Request patient/Observation.read. Don't request access to medications if you don't need them. This principle of least privilege enhances security and user trust.

Real-World Applications

Clinical Decision Support

Apps that help clinicians make treatment decisions. Example: A drug interaction checker that reads the patient's current medications and allergies from the EHR, checks for interactions, and displays warnings.

Without SMART, this would require embedding the functionality directly in the EHR (expensive, vendor-specific) or manually entering data (error-prone, time-consuming). With SMART, the app launches from the EHR and automatically has the context it needs.

Patient Portals and Personal Health Records

Apps that give patients access to their own data. Apple Health, for instance, uses SMART on FHIR to download medical records from participating hospitals directly to iPhones.

Patients can view their lab results, immunization history, and medications across multiple providers in one place - without asking each provider for separate access.

Research and Analytics

Researchers can build apps that request patient consent and then pull relevant clinical data for studies. The SMART framework ensures proper authorization while FHIR standardizes the data format.

Specialized Tools

Calculators, risk assessors, treatment planners - specialized clinical tools that enhance EHR functionality without requiring EHR vendors to build them.

Security and Privacy Considerations

Consent Management

Users must explicitly approve what data apps can access. The EHR shows a consent screen listing requested permissions. Users can deny access or approve with conditions.

Token Security

Access tokens should be:

• Transmitted only over HTTPS
• Stored securely (not in browser local storage)
• Short-lived (expire after hours or days)
• Revocable (user can remove access anytime)

Audit Trails

EHRs log when apps access data. This creates accountability - if an app misuses access, there's a record of what was accessed when.

App Validation

Organizations like HL7 and CARIN Alliance certify SMART apps, verifying they follow security best practices. Hospitals often require certification before allowing apps in their environment.

Challenges and Limitations

Variable Implementation

While SMART is a standard, EHR vendors implement it differently. Some support all scopes, others only a subset. Some have robust app galleries, others make apps hard to discover.

Performance

SMART apps make API calls to retrieve data. If the EHR's FHIR API is slow, the app is slow. Network latency adds delay compared to native EHR functionality.

Data Coverage

Not all data in an EHR is available via FHIR APIs. Legacy data or vendor-specific information might not be accessible to SMART apps.

User Experience

Launching an app, reviewing permissions, and waiting for authorization adds friction compared to built-in EHR features. Apps must provide enough value to justify this overhead.

The Future of SMART on FHIR

Regulatory requirements are accelerating adoption. The 21st Century Cures Act in the US mandates that certified EHRs support patient access via standardized APIs - SMART on FHIR is the de facto implementation.

As more EHRs support SMART, the app ecosystem grows. Developers can build once and reach millions of users. Hospitals can choose best-of-breed apps rather than being locked into vendor-provided functionality.

New specifications extend SMART's capabilities:

• SMART App Launch: Enhanced launch workflows and contexts
• Bulk Data Export: Efficiently export large datasets
• CDS Hooks: Real-time clinical decision support integrated into workflow

Getting Started with SMART on FHIR

For developers:

• Start with the SMART on FHIR sandbox - test environments from major vendors
• Use client libraries (JavaScript, Python, Java) that handle OAuth complexity
• Follow security best practices for token handling
• Request minimal scopes - only what your app truly needs
• Test with multiple EHRs to ensure portability

For healthcare organizations:

• Verify your EHR supports SMART on FHIR (most major vendors do)
• Establish app vetting processes (security reviews, certification requirements)
• Educate clinicians about app benefits and risks
• Monitor app usage and data access patterns
• Plan for the app economy - budgeting for subscriptions, support, etc.

The Bottom Line

SMART on FHIR represents a fundamental shift in healthcare IT. For decades, EHRs were walled gardens. SMART opens them up, enabling an ecosystem of applications that enhance functionality without requiring vendor development.

The standard balances openness with security. Apps get the data they need through standard APIs, but only with explicit user consent and strong authentication. This protects patient privacy while enabling innovation.

As healthcare embraces interoperability, SMART on FHIR is the enabling technology. It's not just about technical standards - it's about giving clinicians better tools, giving patients control of their data, and giving developers the platform to innovate in healthcare.