SMART on FHIR App Development Explained

What does "SMART on FHIR app" mean?

A SMART on FHIR app is an application that launches inside an electronic health record, already knowing which patient is open and who is signed in.

SMART stands for Substitutable Medical Applications and Reusable Technologies. The name is a mouthful, but the idea is simple: write an app once and run it in any EHR system that supports the standard.

FHIR handles the data, like any other healthcare API. SMART handles everything around it — who is allowed in, what they can see, and how the app gets launched in the first place.

The result for a clinician is that your feature appears where they already work, with the right chart open, instead of in a separate tab they have to log into and search.

What is SMART in FHIR, exactly?

Fast Healthcare Interoperability Resources gives you an API for clinical data, and differs from older standards in ways our FHIR vs HL7 comparison sets out. On its own it says nothing about authentication.

SMART fills that gap. It is a profile layered on the FHIR standard that specifies authentication and authorization using OAuth 2.0 and OpenID Connect.

So a plain FHIR app has to solve login, permissions, and patient context itself, differently for every vendor. A SMART app gets those solved the same way everywhere.

That is the whole value: it standardizes the awkward parts so an app developer can build once rather than per-EHR.

FHIR vs SMART on FHIR: the key differences

They are complementary rather than competing, and the distinction matters when scoping work.

FHIR defines the data model and the API. Which FHIR resource types exist, what fields they carry, how you query them.

SMART on FHIR defines how an app is launched, authenticated, and scoped. It sits on top and assumes FHIR underneath.

You can use FHIR without SMART — a backend service pulling health records overnight needs no user context at all. You cannot really use SMART without FHIR, because there would be no data to reach.

In practice the choice comes down to whether a human is in the loop. Clinician-facing means SMART; server-to-server usually does not.

How SMART on FHIR works

The launch sequence is the part worth understanding, because most integration bugs live there.

The EHR launches your app with a launch token and the address of its FHIR server. Your app then redirects the user to the authorization endpoint, requesting specific scopes.

The user is already signed into the EHR, so they are not asked to log in again. The authorization server returns a code, which your app exchanges for an access token.

That access token comes back alongside the context: which patient is open, which encounter, which user. Every subsequent call to the FHIR API carries the token.

Two launch styles exist. An EHR launch starts from inside the chart. A standalone launch starts from your app, and the user picks a patient after signing in.

Does Epic support SMART on FHIR?

Yes. Epic supports SMART on FHIR for both provider-facing and patient-facing apps, and it is the standard route for third-party integration.

Oracle Health, athenahealth, eClinicalWorks, MEDITECH, and most other major vendors support it too. Coverage of specific FHIR resources varies more than support for the launch standard itself.

What varies most is the review process. Epic requires registration and a vendor review before production access, and that queue is the least predictable part of any timeline.

Plan for it early. The code is usually finished long before the paperwork is.

Common use cases

The apps that succeed share a trait: they do one thing at the moment of care, without asking the clinician to go anywhere.

Clinical decision support is the classic use case — a risk score, a guideline prompt, or a drug interaction check surfaced against the open chart.

Specialty calculators and scoring tools work well, because the alternative is a paper card or a separate website.

Patient-facing apps use the same standard to let people reach their own health data from a portal or a phone.

Registry and quality reporting tools pull structured clinical data without anyone re-keying it into a second system.

Steps to build a SMART on FHIR app

The build itself follows a predictable path.

Decide the launch type. EHR launch or standalone changes your entire authentication flow, so settle it first.

Register with the vendor. You need a client ID, redirect URLs, and an agreed scope list before you can test against anything real.

Build against a sandbox. Every major vendor offers one. Sandboxes are cleaner than production, which is both convenient and misleading.

Request the narrowest scopes that work. Reviewers question broad scope requests, and so do hospital security teams.

Handle the unhappy paths. Expired tokens, missing FHIR data, and patients with no matching record are the cases that break demos.

Submit for review. Then wait, and use the time to test against a second EHR.

Security considerations

SMART inherits its security model from OAuth 2.0 and OpenID Connect, which is a good foundation and still easy to misuse.

Scope discipline matters most. Request patient-level access rather than user-level whenever the app only needs one chart, and never ask for write scopes you do not use.

Treat the access token as a secret with a short life. Do not log it, do not store it in local storage, and refresh it properly rather than extending its lifetime.

Everything the app touches is protected health information, so the usual obligations apply: encryption in transit, audit logging, and a business associate agreement with whoever hosts it.

Assume a hospital security review before go-live. Ours is easier because we document the scopes and data flow as we build rather than reconstructing them afterward.

Benefits, honestly assessed

The real benefit is distribution. An app that supports SMART can be sold to any healthcare organization running a compliant EHR, instead of needing bespoke work per customer.

The second is adoption. Living inside the clinical workflow beats living in a browser bookmark, and usage numbers show it clearly.

The honest limitation is that support is uneven. Two EHRs can both claim SMART compliance and still differ in which FHIR resources they expose, so "build once" is closer to "build once, then adjust twice."

It is still far cheaper than the alternative, which is a separate integration per customer.

What data a SMART app can actually reach

A SMART app sees exactly what its granted scopes allow, and nothing beyond that.

Patient-level scopes limit data access to the chart currently open. User-level scopes widen it to everything the signed-in clinician could see for themselves.

Which healthcare data is available depends on the FHIR resources the vendor exposes. Demographics, conditions, medications, allergies, labs, and vitals are close to universal.

Past that, coverage thins quickly. Notes, imaging, and scheduling vary by EHR, and write access varies far more than read access does.

Check the vendor resource list before promising a feature to a customer. Most SMART on FHIR apps that stall do so because a resource someone assumed would be there simply is not.

The wider SMART Health ecosystem reaches past apps too. SMART Health Cards and Links use the same foundations to make records portable outside the EHR.

Integrating SMART apps into a healthcare organization

Integrating SMART apps into a healthcare system is as much organisational work as engineering.

Healthcare organizations run their own security review before any third-party application touches production, and the reviewers are usually not developers.

Expect questions about where data is stored, how long tokens live, who can see audit logs, and what happens to health data if your company is acquired or shuts down.

App launches also need configuring on the EHR side by someone with administrative rights. That means booking time with a team that has its own backlog.

Budget calendar time for this rather than only engineering time. Data exchange agreements and review queues routinely take longer than writing the app did.

The practices that move fastest prepare the security answers before they are asked, and treat the review as a deliverable rather than an obstacle.

Where this fits

SMART on FHIR is one piece of a wider picture. Most products that use it also need older feeds, because hospitals rarely run on one standard alone.

If you are weighing the options, our comparison of what EHR integration costs covers the budget side, and our FHIR integration services page covers the engineering.

For the event-driven traffic that FHIR does not carry well, HL7 v2 interfaces are still doing the work in most hospitals.