SMART on FHIR Development
A healthcare app is only as useful as the data it can securely reach. SMART on FHIR gives applications a standard way to launch inside an EHR, authenticate the user, and pull exactly the FHIR data they are authorized for. Peerbits builds that launch, authorization, and data-access layer so your team can focus on the application itself.
Healthcare Application
Authorization
OAuth2 · OIDC
FHIR API
scoped access
EHR
patient context
SMART on FHIR Development for Connected Healthcare Applications
Once a healthcare application needs real patient or clinical data, the scope changes. It has to launch correctly from inside an EHR session, prove who the user is, request only the data it is actually authorized to see, and stay within whatever access the patient or provider granted — all before it does anything the app was actually built to do.
SMART on FHIR standardizes that layer, so applications don't need a bespoke authorization scheme per EHR. Peerbits implements the launch, authentication, authorization, and FHIR data-access patterns that let your application connect securely to EHR environments, so your team can spend its time on the product rather than reverse-engineering each vendor auth flow.
What Is SMART on FHIR?
SMART on FHIR is a specification that sits on top of FHIR and defines how an application launches, authenticates its user, and obtains a scoped, time-limited token to call a FHIR API — using OAuth 2.0 for authorization and OpenID Connect for identity.
Where FHIR defines the data and the API, SMART on FHIR defines how an application earns the right to call that API in a specific context — a specific patient, a specific user, a specific set of permissions.
SMART ON FHIR APPLICATION LAYERS
Application UI
SMART Launch + OAuth2 / OIDC
FHIR Resource Access (scoped)
SMART on FHIR layers: the application, its launch and authorization layer, and scoped FHIR resource access.
SMART on FHIR Development Services We Provide
Building new clinical, patient, or provider applications with SMART on FHIR launch and data access designed in from the start.
Connecting existing applications to EHR-hosted SMART on FHIR endpoints for app launch and FHIR resource access.
Implementing EHR launch and standalone launch flows so your app opens correctly with the right patient and encounter context.
Implementing OAuth 2.0 and OpenID Connect flows, token handling, and scope design specific to your application needs.
Building the FHIR client logic that reads and writes resources within the access your application has been granted.
Upgrading existing healthcare apps with custom or outdated auth to standards-based SMART on FHIR access.
SMART on FHIR Use Cases
Apps that launch inside a clinician EHR workflow to surface decision support, documentation, or specialty tools.
Apps that let patients securely view their own records, results, and history across connected providers.
Tools that need scoped, in-context access to a patient chart while a provider is actively working in the EHR.
Health tech products that need standards-based, auditable access to EHR data rather than one-off integrations.
Cross-team tools that pull encounter and care-plan data from the EHR into a shared coordination view.
RPM apps that need authorized read/write access to a patient record for device data and alerts.
SMART on FHIR EHR Integration
The EHR launches your app with a launch token identifying the session it is opening from.
The app resolves which patient and encounter the launch applies to, so it opens to the right record.
The app calls the EHR FHIR API for the resources it needs — observations, medications, conditions, and more.
Every call is constrained by the scopes granted at launch, so access stays limited to what was authorized.
SMART ON FHIR APP LAUNCH FLOW
1. EHR Launch
Launch token sent to app2. App Registers
Resolve well-known config3. User Authenticates
OAuth 2.0 authorization4. Consent
Scopes granted5. Access Token
Scoped, time-limited6. Scoped FHIR API Calls
Patient resources accessedSMART on FHIR App Launch Flow — from EHR launch through authentication and consent to scoped FHIR API access.
SMART on FHIR Authentication and Authorization
SMART on FHIR doesn't invent new security mechanisms — it applies established ones consistently. Here is how the pieces fit inside a SMART on FHIR flow specifically.
Provides the authorization framework: your app requests access, the user or EHR grants it, and your app receives a token — never the user credentials.
Adds identity on top of OAuth 2.0, so your app can confirm who the authenticated user is, not just what they are authorized to access.
Scopes define exactly which resources and actions a token allows — for example, read-only access to a single patient observations.
Short-lived tokens, refresh flows, and vendor sandbox/certification steps keep access auditable and limited in practice, not just on paper.
SMART on FHIR Integration Architecture
The right architecture depends on launch type (EHR-hosted or standalone), whether the app runs server-side or as a public client, and how much of the FHIR data model your use case actually touches. We architect for the specific EHR environments and app types involved rather than a one-size-fits-all pattern.
SMART ON FHIR APPLICATION ARCHITECTURE
SMART on FHIR Application
Authorization Server
OAuth2 · OpenID Connect
FHIR Resource Server
scoped resource access
The app coordinates with a separate authorization server and FHIR resource server, typically hosted by the EHR.
A SMART on FHIR token doesn't grant blanket access to a patient chart — it grants access to specific resources under specific scopes, such as read-only Observation data or write access to a single Condition. Designing the right scope set for your application is part of the implementation work, not an afterthought: request too little and the app breaks; request too much and it won't pass review with EHR vendors or your own security team.
Our SMART on FHIR Development Process
We start with the use case, not the specification — understanding what the application actually needs to do before designing the launch and authorization layer around it.
STEP 1
We define what the application needs to do, who launches it, and what data and actions it requires.
STEP 2
We assess the target EHR SMART on FHIR support, available resources, and any vendor-specific constraints.
STEP 3
We design the launch type, token handling, and FHIR access pattern the application will use.
STEP 4
We build the launch flow, OAuth 2.0/OpenID Connect integration, scopes, and FHIR client logic.
STEP 5
We test against EHR sandboxes and realistic launch scenarios, including edge cases like token expiry and revoked consent.
STEP 6
We support the application through vendor review or certification processes and after it is live in production.
SMART on FHIR vs. FHIR Integration
SMART on FHIR and general FHIR integration solve related but distinct problems, and most application projects need both.
| FHIR Integration | SMART on FHIR | |
|---|---|---|
| Solves | Exchanging structured healthcare data between systems | Launching and authorizing an application to access that data |
| Core concern | Resource mapping, API design, data exchange | Authentication, authorization, launch context |
| Typical actor | System-to-system integration | A user-facing application inside or alongside an EHR |
| Built on | FHIR resources and RESTful APIs | FHIR APIs, plus OAuth 2.0 and OpenID Connect |
| When you need it | Any time systems exchange FHIR data | Any time an application needs to launch and authenticate within an EHR |
Need the data-exchange side too? See FHIR Integration Services.
Why Choose Peerbits for SMART on FHIR Development?
We build against the actual launch, token, and scope mechanics — not a simplified version of the spec.
Our teams have implemented app launch and authorization against leading EHR platforms SMART on FHIR environments.
We size access scopes to what your application actually needs, which matters for both security review and vendor approval.
We stay involved through EHR vendor review processes and ongoing maintenance as SMART on FHIR profiles evolve.
SMART on FHIR Project Experience
Every SMART on FHIR engagement starts with the launch context: is this an EHR-hosted app, a standalone app, or both, and what does the application actually need to read or write once it is authorized. From there, the approach depends on the target EHR specific SMART on FHIR implementation, the scopes required, and whatever vendor review or sandbox certification process applies.
Because EHR vendors implement SMART on FHIR with real differences in behavior, we would rather walk you through relevant project experience and technical approach directly than summarize it in generic terms here. If you are evaluating a partner for a SMART on FHIR project, we are glad to go through the specifics for your target EHR and application.
Talk to a Healthcare Integration ExpertReal SMART on FHIR integrations, EHR connectivity, and healthcare application delivery.
Healthtech ,
See how a configurable interoperability layer can receive healthcare data from heterogeneous systems, validate and normalize messages, map them into standards-based FHIR structures, validate profiles, and reliably deliver data to downstream clinical
Healthtech ,
Explore how Peerbits engineers an end-to-end Remote Patient Monitoring (RPM) platform: device data ingestion, continuous monitoring, intelligent alerts, care-team workflows, clinical interventions, and FHIR/EHR interoperability.
Healthtech ,
Peerbits designed a reusable interoperability demonstration connecting a React and Node.js application to Epic's FHIR R4 sandbox through SMART on FHIR authentication — proving real EHR connectivity, multi-resource retrieval, governed write-back, and
Discuss Your SMART on FHIR Project
Share the EHR environment and the data your application needs — we will walk you through a launch and authorization approach before you commit to anything.
SMART on FHIR is an open standard built on top of FHIR that defines how applications authenticate, launch, and get scoped access to a patient's or provider's data within an EHR, using OAuth 2.0 and OpenID Connect.
SMART on FHIR development is the work of building applications that implement the SMART on FHIR launch, authorization, and FHIR data-access patterns so they can run securely inside or alongside an EHR.
SMART on FHIR development services cover app launch integration, OAuth 2.0 and OpenID Connect implementation, scope design, FHIR resource access, testing against EHR sandboxes, and deployment and support.
EHRs that support SMART on FHIR expose an authorization server and FHIR API. An app registers with the EHR, is launched from within the EHR or standalone, authenticates through OAuth 2.0 and OpenID Connect, and receives an access token scoped to specific FHIR resources.
A SMART on FHIR application is a web or mobile app built to the SMART on FHIR specification, able to launch within an EHR session or standalone, authenticate the user, and access FHIR resources within its granted scope.
In an EHR launch, a user opens the app from within the EHR, which provides launch context such as the current patient and redirects to the app. In a standalone launch, the app initiates its own authorization flow and the user signs in directly. Both end with the app receiving an access token scoped to specific resources.
SMART on FHIR uses OpenID Connect on top of OAuth 2.0, letting an application verify a user's identity alongside receiving authorized access to FHIR resources.
OAuth 2.0 is the authorization framework SMART on FHIR is built on. It defines how an application requests and receives a scoped access token without handling the user's EHR credentials directly.
FHIR defines the healthcare data resources and the API used to exchange them. SMART on FHIR defines how applications authenticate, launch, and obtain authorized, scoped access to that FHIR API within an EHR context.
Most major EHR platforms with FHIR APIs, including Epic, Oracle Health (Cerner), and athenahealth, support SMART on FHIR app launch and authorization to varying degrees. Exact capabilities and certification requirements should be confirmed per vendor and deployment.
Yes. Access is scoped through OAuth 2.0 scopes and limited to what the user or patient authorizes, following standard security practices such as short-lived tokens, refresh tokens, HTTPS, and vendor-specific sandbox or certification processes.
Peerbits provides end-to-end SMART on FHIR development services, including app launch integration, authentication and authorization implementation, FHIR data access, testing, deployment, and ongoing support.
Have more questions?
Ask our expertsTechnical guides on SMART on FHIR, OAuth 2.0, EHR launch, FHIR data access, and healthcare application architecture.
