Skip to content
FHIRVendors

Vendor directory

SMART on FHIR Developers: Companies That Build EHR-Launched and Patient Apps

SMART on FHIR developers build applications that authorize and launch against FHIR servers using the HL7 SMART App Launch framework: clinician apps embedded in the EHR, patient-facing apps that connect to a portal account, and backend services. The companies listed here offer SMART on FHIR development. The guidance below explains what the work involves and how to check a team knows it.

Find a FHIR PartnerCompare vendors

5 listed companies

Not a ranking · affiliated company shown first and labelled · others alphabetical

What SMART on FHIR development involves

SMART App Launch defines how an app discovers a server’s authorization endpoints, obtains OAuth 2.0 tokens with scoped access, and receives launch context such as the current patient or encounter. The current major version is SMART App Launch 2.x, which added granular scopes and made PKCE required. Our SMART on FHIR guide covers the concepts.

App typeLaunch / auth patternTypical use
Provider-facing (EHR launch)Launched from inside the EHR with patient and user contextClinical decision support, specialty workflows, visualizations
Patient-facing (standalone launch)Patient signs in with their portal credentials and authorizes the appPersonal health records, care programs, research apps
Backend servicesClient credentials with a signed JWT assertion, no user presentPopulation data sync, bulk export, analytics
SMART app types
GET /fhir/.well-known/smart-configuration
Accept: application/json
Discovery: a SMART-enabled server publishes its authorization endpoints and capabilities here.

When you need specialist SMART developers

  • Your app must run inside one or more EHRs, where each has its own registration process, launch quirks and UI constraints (such as embedded browser limitations).
  • You need to pass EHR app review or customer security review.
  • You are combining SMART launch with write-back, CDS Hooks or other workflow integration.
  • You need a single codebase that works across several EHRs without per-site forks.

See our SMART on FHIR development service overview for typical project scope.

How to evaluate SMART on FHIR developers

  • Multi-EHR delivery. Ask which EHRs their SMART apps have launched in, in production, and how they handled differences in supported scopes and context.
  • Security practice. Correct use of PKCE, state, token storage, refresh token handling and least-privilege scopes. See FHIR security.
  • Testing. Use of public SMART launchers and EHR sandboxes, plus automated tests for launch and token flows.
  • UX for embedded contexts. Apps inside an EHR frame need to be fast, small-screen tolerant and consistent with clinical workflows.
  • Upgrade awareness. Familiarity with differences between SMART v1 and v2 scope syntax.

Ask finalists to demonstrate a working launch against a public or EHR vendor sandbox early in the selection process. Watching a team debug a failed launch, for example a mismatched redirect URI or a missing launch scope, tells you a lot about how they will handle production issues.

Red flags

  • Requesting broad scopes such as user/*.* (or user/*.cruds) ‘to be safe’.
  • Storing access tokens in browser local storage without a clear threat model.
  • Only ever testing against a generic public sandbox and never an EHR-specific one.
  • No plan for how each customer will enable the app.

How SMART on FHIR developers are listed

Companies appear here when they publicly offer SMART on FHIR development. Listings are not rankings, and sponsored placements are labelled. Check each profile’s documented EHR platforms and review date, and read our editorial policy for how profiles are verified.

Frequently asked questions

What is a SMART on FHIR app?

An application that uses the HL7 SMART App Launch framework to authorize with OAuth 2.0 and access FHIR data, typically launched from inside an EHR or by a patient from outside it. See what SMART on FHIR is.

Will one SMART app work in every EHR?

The standard makes this far more achievable, but differences remain in supported scopes, resources, launch context and app registration. Expect some per-EHR configuration and testing.

What is the difference between EHR launch and standalone launch?

EHR launch starts inside the EHR and passes context such as the current patient. Standalone launch starts outside the EHR; the user signs in and, if needed, selects a patient during authorization.

Do SMART apps need EHR vendor approval?

It depends on the EHR and the app type. Most require developer registration, and provider-facing apps generally need activation by each healthcare organization. Check the relevant EHR integration page for specifics.

What changed in SMART App Launch 2.0?

Version 2.0 introduced granular scopes with a new syntax (for example patient/Observation.rs instead of patient/Observation.read), required PKCE for authorization code flows, and added capabilities such as token introspection. Many servers accept both v1 and v2 scope styles during the transition.

Related FHIR services

Related guides

Find the Right FHIR Integration Partner for Your Healthcare Project

Tell us what you need to build or connect. We review every request and share a short list of relevant vendors from our directory — no obligation.

Explore Vendors Get vendor recommendations