SMART on FHIR App Development Services

The SMART on FHIR guide explains each flow in depth. Most products end up needing more than one, for example an EHR-launched UI plus a backend service for data refresh.

• Authorization implementation following the SMART App Launch specification: discovery via `.well-known/smart-configuration`, authorization code flow with PKCE, launch context handling, token refresh and, for backend services, asymmetric client authentication with signed JWTs.
• Scope design: the narrowest scopes that support the workflow. SMART 2.x scopes such as `patient/Observation.rs` express read and search separately, which matters when EHRs review your request.
• Front-end application sized for EHR embedding, with handling for iframe or new-window launch, session timeouts and accessibility.
• Data access layer using US Core-conformant queries, with defensive handling when optional elements are absent.
• EHR onboarding package: app descriptions, security questionnaire answers, redirect URIs, JWKS endpoint and test evidence for each target platform.

GET /oauth2/authorize?response_type=code
  &client_id=my-smart-app
  &redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
  &launch=xyz123
  &scope=launch%20openid%20fhirUser%20patient%2FPatient.r%20patient%2FObservation.rs
  &state=af0ifjsldkj
  &aud=https%3A%2F%2Fehr.example.org%2Ffhir
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256

SMART is a common specification, but every EHR implements registration, supported scopes and launch behavior a little differently. Expect per-platform work for:

• Developer program enrollment and app registration (see our Epic and Oracle Health integration pages for platform specifics).
• Differences in supported SMART versions, scope syntax and refresh token policies.
• How the app is surfaced in clinician workflows, which is usually configured by each health system's EHR team.
• Customer-by-customer activation, where each health system approves and enables the app on its own instance.

1. Workflow design with clinicians: where in the EHR the app is launched, what it shows in the first seconds, and what (if anything) it writes back.
2. Data feasibility check: confirm the needed data is available via FHIR on each target EHR, at the required granularity.
3. Auth-first prototype: complete launch and token exchange against sandboxes before investing in UI.
4. Build and usability testing inside realistic EHR frames and screen sizes.
5. Security review and registration with each EHR vendor and pilot customer.
6. Pilot go-live, measurement, then rollout to additional sites.

Browse SMART on FHIR developers and put these questions to your shortlist:

• Which SMART apps have you taken from sandbox to live clinical use, and on which EHRs?
• Do you implement SMART 2.x features such as PKCE and granular scopes, and how do you fall back when an EHR supports only 1.0 behavior?
• Where do you store tokens and private keys, and how are keys rotated?
• How do you handle the app being opened for the wrong patient or with an expired session?
• Who prepares security questionnaires and marketplace submissions?

SMART apps are usually built as a fixed-scope MVP for one EHR followed by phased expansion to additional platforms, or by a dedicated product team on a monthly rate. Cost drivers include the number of target EHRs, read-only versus write-back, UI complexity, clinical validation needs, and any EHR program or marketplace fees, which are set by the EHR vendor rather than the developer. Ongoing costs include EHR upgrade regression testing and certificate and key rotation.