SMART on FHIR Development
Build the app clinicians can launch from inside their EHR — without building your own auth from scratch
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
The hard part of a clinical app usually isn't the app
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?
A launch and authorization standard built on top of 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
The layer between your application and a live EHR session
SMART on FHIR Application Development
Building new clinical, patient, or provider applications with SMART on FHIR launch and data access designed in from the start.
- EHR launch and standalone launch flows
- OAuth 2.0 + OpenID Connect integration
- Scoped FHIR resource access
- Patient and provider context handling
SMART on FHIR EHR Integration
Connecting existing applications to EHR-hosted SMART on FHIR endpoints for app launch and FHIR resource access.
- Epic SMART on FHIR integration
- Oracle Health / Cerner SMART apps
- athenahealth SMART on FHIR
- Multi-EHR launch support
SMART on FHIR App Launch Integration
Implementing EHR launch and standalone launch flows so your app opens correctly with the right patient and encounter context.
- EHR-hosted launch implementation
- Standalone launch configuration
- Launch token and context resolution
- Session and encounter binding
SMART on FHIR Authorization and Authentication
Implementing OAuth 2.0 and OpenID Connect flows, token handling, and scope design specific to your application needs.
- Authorization code + PKCE flow
- OpenID Connect identity layer
- Token refresh and revocation
- Scope design and access review
SMART on FHIR API Integration
Building the FHIR client logic that reads and writes resources within the access your application has been granted.
- FHIR resource client development
- Scoped read and write operations
- Resource-level error handling
- Refresh token and session management
SMART on FHIR Application Modernization
Upgrading existing healthcare apps with custom or outdated auth to standards-based SMART on FHIR access.
- Legacy auth replacement
- SMART on FHIR retrofit
- Scope redesign for least-privilege access
- EHR sandbox testing and certification support
SMART on FHIR Use Cases
Where a standard launch and auth layer actually gets used
Clinical Applications
Apps that launch inside a clinician EHR workflow to surface decision support, documentation, or specialty tools.
Patient-Facing Applications
Apps that let patients securely view their own records, results, and history across connected providers.
Provider Applications
Tools that need scoped, in-context access to a patient chart while a provider is actively working in the EHR.
Digital Health Platforms
Health tech products that need standards-based, auditable access to EHR data rather than one-off integrations.
Care Coordination Applications
Cross-team tools that pull encounter and care-plan data from the EHR into a shared coordination view.
Remote Patient Monitoring Applications
RPM apps that need authorized read/write access to a patient record for device data and alerts.
SMART on FHIR EHR Integration
What actually happens when your app opens inside an EHR
EHR App Launch
The EHR launches your app with a launch token identifying the session it is opening from.
Patient Context
The app resolves which patient and encounter the launch applies to, so it opens to the right record.
FHIR Resource Access
The app calls the EHR FHIR API for the resources it needs — observations, medications, conditions, and more.
Authorization and Permissions
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
Identity and access, handled by the protocol instead of your app
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.
OAuth 2.0
Provides the authorization framework: your app requests access, the user or EHR grants it, and your app receives a token — never the user credentials.
OpenID Connect
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 and Permissions
Scopes define exactly which resources and actions a token allows — for example, read-only access to a single patient observations.
Secure Application Access
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
Designed around where your app runs and who launches it
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.
Access is granted resource by resource, not system-wide
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
From use case to a launch-ready application
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.
- 01
STEP 1
Requirements and Use-Case Assessment
We define what the application needs to do, who launches it, and what data and actions it requires.
- 02
STEP 2
FHIR and EHR Capability Assessment
We assess the target EHR SMART on FHIR support, available resources, and any vendor-specific constraints.
- 03
STEP 3
Application and Integration Architecture
We design the launch type, token handling, and FHIR access pattern the application will use.
- 04
STEP 4
SMART on FHIR Implementation
We build the launch flow, OAuth 2.0/OpenID Connect integration, scopes, and FHIR client logic.
- 05
STEP 5
Testing and Validation
We test against EHR sandboxes and realistic launch scenarios, including edge cases like token expiry and revoked consent.
- 06
STEP 6
Deployment and Support
We support the application through vendor review or certification processes and after it is live in production.
SMART on FHIR vs. FHIR Integration
Two different layers of the same problem
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?
Auth and launch handled correctly the first time
Implementation-level SMART on FHIR knowledge
We build against the actual launch, token, and scope mechanics — not a simplified version of the spec.
Experience across major EHR sandboxes
Our teams have implemented app launch and authorization against leading EHR platforms SMART on FHIR environments.
Scope design done deliberately
We size access scopes to what your application actually needs, which matters for both security review and vendor approval.
Support through certification and beyond
We stay involved through EHR vendor review processes and ongoing maintenance as SMART on FHIR profiles evolve.
SMART on FHIR Project Experience
How we approach SMART on FHIR development work
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 ExpertHealthcare interoperability case studies
Real SMART on FHIR integrations, EHR connectivity, and healthcare application delivery.
Healthtech ,
Clinical Research EDC Platform: Configurable eCRF & Study Management
Configure studies and eCRFs, manage participants and visits, capture structured clinical data, and maintain visibility and traceability from one unified research platform.
Healthtech ,
AI Prior Authorization: Intelligent Automation for Healthcare Workflows
A working AI prior authorization use case engineered by Peerbits — AI-assisted clinical evidence gathering, payer rule matching, gap identification, documentation drafting, and human review workflows to accelerate prior authorizations while keeping clinicians in complete control.
Healthtech ,
Building an AI-Powered Clinical Documentation Platform
A working AI clinical documentation platform engineered by Peerbits — demonstrating ambient audio capture, medical speech-to-text, structured SOAP generation, clinical validation flags, ICD-10/CPT coding suggestions, physician review, and FHIR/EHR write-back.
Discuss Your SMART on FHIR Project
Tell us what your app needs to launch and access. We will tell you what it takes.
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.
Frequently asked questions
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 expertsSMART on FHIR and interoperability insights
Technical guides on SMART on FHIR, OAuth 2.0, EHR launch, FHIR data access, and healthcare application architecture.
