A clinician opens her EHR, clicks an icon, and a third-party app slides open inside the same window — already showing the right patient, already logged in, no separate password to type. That experience isn’t a custom integration some hospital IT team bolted together over a long weekend. It’s SMART on FHIR, a standards-based framework that lets an app built once run inside almost any electronic health record that supports it.

For most of the EHR era, that kind of portability didn’t exist. An app vendor who wanted to work with three different EHR platforms had to build three different integrations, each with its own proprietary API, its own authentication scheme, and its own maintenance burden. SMART on FHIR — short for Substitutable Medical Applications, Reusable Technologies — was designed specifically to end that. It borrows the idea behind a smartphone app store: write to a common standard once, and the app can install and run on any platform that implements it.

What problem is SMART on FHIR actually solving?

Before FHIR (Fast Healthcare Interoperability Resources) and SMART existed, EHR vendors exposed data through proprietary interfaces if they exposed it at all. A developer who wanted to build, say, a pediatric growth-chart calculator or a cardiovascular risk tool had to negotiate custom access with each EHR vendor, learn a bespoke data model, and rebuild much of the integration work for every new client.

SMART on FHIR combines two things that solve different halves of the problem:

  • HL7 FHIR defines the data itself — a standardized way to represent patients, medications, lab results, conditions, and other clinical resources as predictable, well-documented API calls.
  • The SMART App Launch framework defines how an app gets permission to see that data — using OAuth2 and OpenID Connect, the same authorization approach that powers “Sign in with Google” or “Sign in with Facebook” buttons across the web, adapted for clinical context.

Put together, an app developer can write one codebase that requests a patient’s vitals or medication list the same way regardless of which EHR is on the other end, then rely on a standard security handshake to get authorized access. The specification itself is maintained by the SMART Health IT project (a collaboration originally based at Boston Children’s Hospital and Harvard Medical School) and has been folded into HL7’s FHIR implementation guide ecosystem, so it evolves alongside the FHIR standard rather than as a separate, competing spec.

How does the SMART app launch actually work?

The mechanics matter because they explain both the security model and why some apps behave differently depending on how they’re opened. SMART defines two primary launch patterns.

EHR launch

In an EHR launch, the app is started from inside the EHR itself — a clinician clicks a tile or button in the chart, and the EHR hands the app two things: the address of its FHIR server (the iss parameter) and an opaque launch token that represents the current session context, such as which patient and encounter are active. The app then walks through the OAuth2 authorization sequence, presenting that launch token back to the authorization server, which responds with an access token plus contextual details — for example, a patient identifier telling the app which chart it’s allowed to read.

Standalone launch

In a standalone launch, there’s no existing EHR session to inherit. A patient might open a personal health app on their phone, or a clinician might launch a tool from outside the record entirely. Here the app has to establish its own context: it discovers the authorization and token endpoints (often via a .well-known/smart-configuration.json file the FHIR server publishes), then requests specific launch-context scopes like launch/patient so the authorization server knows to ask the user which patient record to attach to the session.

The OAuth2 handshake, in short

Both launch types converge on the same core exchange:

  1. The app redirects the user to the EHR’s authorization endpoint, specifying which FHIR resources it wants (its scopes), a redirect URI, and a state value.
  2. The authorization server authenticates the user (and, in an EHR launch, may skip this if the clinician is already logged in) and asks them to approve the requested access.
  3. The server sends the app a short-lived authorization code.
  4. The app exchanges that code for an access token — and, for apps that need ongoing access, a refresh token — via a direct, back-channel request.
  5. The app calls the FHIR API, attaching the access token as a bearer credential on every request.

Scopes follow a defined syntax, such as patient/Observation.read (read a specific patient’s observations) or user/Patient.read (read patient records the logged-in user is permitted to see). This granularity is deliberate: it lets a patient or an organization authorize an app to see immunization records without also handing over, say, behavioral health notes.

What does an app actually need to register?

An app can’t simply appear and start requesting data. Before an EHR will recognize it, a developer typically registers the app with that platform, providing a fixed launch URL and one or more redirect URIs the authorization server will trust. Larger EHR vendors run their own developer programs for this — Cerner’s Code Console and Epic’s App Orchard being two of the more visible examples circa 2021 — where a developer configures scopes, launch URIs, and FHIR version support before an app can be tested against sandbox data and eventually approved for production use with real patients. Registration requirements, review rigor, and approval timelines vary by vendor; there’s no single universal app store, though the SMART framework is what makes it possible for one app codebase to go through that process with multiple vendors instead of rebuilding the integration from scratch each time.

Where do app galleries fit in?

Because SMART apps are meant to be reusable across EHR platforms, a natural next step was building places to discover them. The SMART Health IT project maintains a public app gallery listing both commercial and open-source SMART on FHIR apps across categories like data visualization, clinical decision support, and general FHIR tooling — useful for a health system that wants to see what already exists before commissioning something custom. Individual EHR vendors also run their own curated marketplaces or “app store” style directories tied to their developer programs, which typically list only apps that have gone through that vendor’s own registration and review process.

It’s worth being precise about what these galleries are and aren’t. They function more like directories than tightly policed app stores — inclusion in a public gallery isn’t the same as an EHR vendor certifying an app for clinical use, and health systems still generally need to complete their own registration, testing, and security review before deploying an app in a live clinical environment.

What are people actually using SMART on FHIR apps for?

The use cases that have gained the most traction tend to fall into a few buckets:

  • Clinical decision support — risk calculators, dosing tools, and scoring systems (cardiovascular risk, pediatric growth percentiles, and similar point-of-care calculators are common examples) that pull patient data automatically instead of requiring manual entry.
  • Patient-facing apps — tools patients authorize directly, often through a standalone launch, to pull their own records into a personal health app, a research study, or a chronic-disease management tool.
  • Specialty and workflow tools — narrower applications built for a single specialty or task, such as identifying patients who match a clinical trial’s eligibility criteria, that would be hard to justify building directly into a general-purpose EHR.
  • Population and research tooling — apps and services that work with FHIR’s bulk-data capabilities to analyze cohorts of patients rather than one chart at a time, an area that’s become more relevant as health systems look to combine clinical and other data sources.

What connects these is that each one is, in principle, EHR-agnostic: built to the SMART and FHIR specifications rather than to one vendor’s proprietary interface, so the same app can in theory be deployed across health systems running different EHR platforms, subject to that system’s own IT and security review.

Why is ONC pushing this now?

SMART on FHIR has existed as an open specification since the early 2010s, but it moved from “nice option” to “expected capability” with ONC’s 21st Century Cures Act Final Rule. That rule, finalized by the Office of the National Coordinator for Health Information Technology, adds a new certification criterion — commonly referenced as §170.315(g)(10), the standardized API criterion — that requires certified health IT to expose a FHIR-based API built on HL7 FHIR Release 4 and aligned with the SMART Application Launch framework for authorization.

Under the rule, certified health IT developers are required to update their technology and make certified FHIR-based APIs available to their customers, with a compliance deadline set for December 31, 2022. The requirement covers both patient-level access (an individual retrieving their own records through an app of their choosing) and, separately, population-level access intended for broader data services. ONC’s rule doesn’t mandate that a single app store or gallery be used — it mandates the underlying API and authorization standard, leaving the marketplace layer to develop on top of it.

The practical effect for health IT teams: by the time this requirement takes hold, “does your app support SMART on FHIR” stops being an optional integration question and starts being closer to a baseline expectation, at least for any EHR platform certified under ONC’s program.

What should health IT teams keep in mind before adopting a SMART app?

A few things are easy to overlook:

  • Standards compliance isn’t the same as vendor compatibility. Two EHRs can both implement SMART and FHIR correctly and still have subtly different behavior in areas the spec leaves open to interpretation — testing against each target platform’s sandbox before going live is still necessary.
  • Scopes should be reviewed deliberately. Because SMART scopes can be requested at a fine-grained resource level, it’s worth confirming an app is only asking for the data categories it actually needs, rather than broad read access “just in case.”
  • Refresh tokens and session length matter for patient-facing apps. A poorly configured token lifecycle can either force patients to re-authenticate constantly or leave access open longer than intended — this is a security and privacy conversation, not just a technical one.
  • Gallery listing isn’t a security clearance. Treat any third-party app, gallery-listed or not, as something that needs its own review before it touches production patient data.

Frequently Asked Questions

What does SMART on FHIR stand for?

SMART stands for Substitutable Medical Applications, Reusable Technologies. Combined with FHIR (Fast Healthcare Interoperability Resources), SMART on FHIR is a framework and specification that lets health apps use standardized FHIR APIs and OAuth2-based authorization to run across different EHR platforms without custom, vendor-specific integration work for each one.

Is SMART on FHIR required by law?

Not directly, but ONC’s 21st Century Cures Act Final Rule requires certified health IT developers to support a standardized FHIR API built around the SMART Application Launch framework, under certification criterion §170.315(g)(10). Developers have a compliance deadline of December 31, 2022, to make this API available to customers.

What’s the difference between an EHR launch and a standalone launch?

An EHR launch starts inside an active EHR session, so the platform hands the app existing context like the current patient and encounter. A standalone launch starts outside the EHR — for example, a patient opening a personal app — so the app must establish its own authorization and request context, such as which patient record to attach to, as part of the OAuth2 flow.

Do all SMART on FHIR apps work the same way across every EHR?

They’re built to the same open specification, but individual EHR vendors still run their own developer registration, sandbox testing, and approval processes, and some implementation details can vary between platforms. An app conforming to the SMART and FHIR standards is designed to be portable, but health IT teams should still test and review each integration before deploying it in a live clinical environment.

The SMART App Gallery, maintained by the SMART Health IT project, is a public directory of commercial and open-source SMART on FHIR apps organized by category, such as clinical decision support or data visualization. It’s a discovery tool, not a certification body — listing in the gallery doesn’t substitute for a health system’s own security and clinical review before deployment.