SMART on FHIR · App Launch 2.0 · OAuth 2.0 · CDS Hooks
Peerbits builds SMART on FHIR applications that launch natively inside Epic, Cerner, Athenahealth, and eClinicalWorks — delivering AI coding, prior authorization, risk scoring, and clinical decision support directly at the point of care, without a separate login or context switch.
SMART Apps Live
EHR Platforms
Avg. App Go-Live
GRANTED SCOPES
Compliance & Standards
SMART on FHIR defines three distinct launch architectures — each suited to a different clinical or operational use case. Peerbits has production implementations of all three, and builds apps that can support multiple launch patterns simultaneously from a single codebase.
EHR LAUNCH
Clinician clicks app inside EHR
EHR
(Epic / Cerner)
Auth Server
OAuth 2.0
SMART App
patient + encounter context
FHIR R4 Server
Bearer token · patient data
Use case: clinical workflow apps
STANDALONE LAUNCH
Patient or provider opens app directly
Browser / App
Patient portal / PWA
Auth Server
+ user login
SMART App
no EHR context · user selects patient
FHIR R4 Server
user-scoped data access
Use case: patient access apps
BACKEND SERVICES
System-level, no user interaction
Backend System
Cron / pipeline / API
Token Endpoint
client_credentials
System Client
system/* scopes · no user session
FHIR R4 Server
Bulk access · system-level scope
Use case: server-to-server integration
// Figure 1 — Three SMART on FHIR launch patterns. EHR Launch for embedded clinical apps, Standalone Launch for patient-facing apps, Backend Services for system-to-system automation. Peerbits implements all three.
REAL-WORLD CHALLENGES
The SMART App Launch specification is well-written — but the distance between the specification and a production app that works correctly inside three different EHRs, handles token expiry gracefully during a clinical workflow, and passes Epic App Orchard review is where most development teams lose months.
The SMART App Launch specification defines a framework — but each EHR vendor implements it with proprietary extensions, different token endpoint behaviors, non-standard launch context parameters, and vendor-specific scope handling. An app that passes Epic's SMART conformance test may silently fail on Cerner because of differences in how launch tokens are issued, how fhirUser is populated, or how token introspection is handled for expired sessions. Building one app that works correctly across EHRs requires deep platform-specific knowledge that goes far beyond the spec.
SMART access tokens typically expire in 300–3600 seconds. In a clinical workflow where a physician opens an app at 9 AM and returns to it three hours later during a long procedure, an expired token triggers an authorization flow that breaks the user experience at the worst possible moment — mid-note, mid-order, or mid-prior auth. Most SMART app frameworks handle token refresh as an afterthought, creating silent failures that appear as data loading errors rather than authentication issues.
Epic's App Orchard certification process is the gateway to production SMART app deployment in the largest EHR install base in the US. The review process evaluates application architecture, scope justification, FHIR resource usage, security posture, and SMART conformance — and first submissions are rejected 60–70% of the time due to underdocumented scope requests, missing PKCE implementation, or non-compliant launch context handling. Each rejection adds 4–8 weeks to the timeline.
SMART Backend Services authentication — used for pipelines, analytics, and server-to-server FHIR access without a user session — requires asymmetric RSA or EC key pairs, JWT client assertions signed with the private key, JWKS URI publication for public key discovery, and token endpoint interaction that varies significantly between EHR implementations. Most developer teams attempting Backend Services auth for the first time spend 4–8 weeks debugging JWT claims, key format issues, and FHIR-specific endpoint quirks that are not documented in the specification.
SMART on FHIR v2.0 introduces granular clinical scopes that control exactly which FHIR resources a connected app can read or write — separated by patient context, user context, and system-level access. Peerbits implements and validates the complete scope model across all four scope categories.
patient/Patient.read
Patient demographics and identifiers
patient/Observation.read
Vital signs, lab results, assessments
patient/Condition.read
Problem list and diagnoses (ICD-10)
patient/MedicationRequest.read
Medications and prescription drug options
patient/AllergyIntolerance.read
Allergies and adverse reactions
patient/DiagnosticReport.read
Lab reports and imaging results
patient/Encounter.read
Visit history and encounter details
patient/*.read
All patient-level resources
user/Patient.read
Patients accessible to the logged-in user
user/Practitioner.read
Provider profiles and credentials
user/Observation.write
Write observations on behalf of user
user/ServiceRequest.write
Create orders and referrals
openid
OIDC ID token with sub claim
fhirUser
FHIR resource URL of authenticated user
profile
UserInfo endpoint access
user/*.read
All resources for the current user
system/Patient.read
All patients — no user session required
system/*.read
All resources — Backend Services only
launch
EHR launch — present active context
launch/patient
Receive patient context in token
launch/encounter
Receive encounter context in token
offline_access
Refresh token for long sessions
online_access
Refresh valid while user is active
system/Group.read
Bulk Data group population access
FULL SOLUTION SUITE
Nine SMART on FHIR engineering services — from EHR-embedded app development and App Orchard certification to Backend Services auth, CDS Hooks integration, and multi-FHIR app deployment strategies.
Full-stack SMART on FHIR application development for EHR-embedded launch — React, Vue, or vanilla JS frontend with SMART authorization client, launch context extraction (patient, encounter, fhirUser), FHIR R4 data layer, and EHR-specific UI/UX guidelines for Epic Hyperdrive and Cerner PowerChart.
Patient-facing and provider-facing standalone SMART applications — OAuth 2.0 authorization code flow with PKCE, user login and patient selection, scoped FHIR data access, and offline_access refresh token management. Mobile-first PWA or native iOS/Android with SMART authorization embedded.
System-level SMART authentication for pipelines, analytics engines, and server-to-server FHIR access — asymmetric RSA/EC JWT client assertions, JWKS URI hosting, key rotation management, system/* scope negotiation, and pre-built auth libraries for Node.js, Python, Java, and .NET targeting Epic, Cerner, and Athena token endpoints.
End-to-end Epic App Orchard submission management — application registration, scope justification documentation, SMART conformance validation, FHIR usage documentation, security review preparation, and first-submission optimization based on 40+ approved applications. Reduces average review timeline from 5–7 months to 8–10 weeks.
Clinical Decision Support Hooks implementation alongside SMART app development — hook registration, CDS service build (order-select, patient-view, appointment-book), suggestion and card response design, and EHR-embedded alert delivery that triggers at clinically relevant moments without breaking physician workflow. SMART context passed to CDS service for patient-specific recommendations.
Architecture and builds for SMART apps that work correctly across Epic, Cerner, Athena, and eClinicalWorks from a single codebase — EHR detection, scope normalization, launch context translation, and EHR-specific UI adaptations. Includes Cerner Code App Gallery submission alongside Epic App Orchard certification.
Security review of existing SMART app implementations — PKCE code verifier/challenge validation, state parameter CSRF protection, token storage security (no localStorage for access tokens), redirect URI validation, and scope minimization audit. ONC certification readiness assessment against §170.315(g)(10) patient access API requirements.
Automated SMART App Launch conformance testing — HL7 Inferno SMART App Launch test suite execution, scope grant validation, token response structure validation, PKCE implementation verification, and launch context population testing against all four EHR platforms. Integrated into CI/CD pipelines for ongoing conformance validation with each release.
Technical advisory for teams planning their first SMART on FHIR implementation — launch pattern selection, scope strategy, EHR platform prioritization, token lifecycle architecture, FHIR data model design for your clinical use case, and integration roadmap across target EHR platforms. Delivered as a 2-week engagement with architecture documentation and decision log.
ENGAGEMENT MODEL
A SMART on FHIR engagement begins with clarity about which EHRs you need to support, what clinical data your app needs access to, and what the launch context is — patient, encounter, or neither. We design the scope model and launch pattern before a line of code is written.
STEP 1
One-week scoping session — identifying target EHR platforms, selecting EHR Launch vs. Standalone vs. Backend Services (or a combination), designing the minimal sufficient scope set for your clinical use case, and mapping FHIR resource access requirements to US Core profiles.
STEP 2
SMART app build in EHR sandbox environments — Epic Sandbox, Cerner Ignite Sandbox, and Athena Preview. Simultaneous App Orchard registration submission with scope justification documentation, PKCE implementation, and SMART conformance validation against Inferno test suite.
STEP 3
Management of Epic App Orchard review process — responding to reviewer questions, submitting conformance evidence, and addressing scope justification requests. Parallel Cerner Code App Gallery submission. Pre-certification security audit covering token storage, PKCE, CSRF, and redirect URI validation.
STEP 4
Production SMART app deployment with monitoring for token error rates, authorization failure patterns, and EHR-specific edge cases. Ongoing support for EHR platform updates (Epic quarterly releases, Cerner Millennium upgrades) that affect SMART implementation behavior.
COMPETITIVE DIFFERENTIATION
Compared to building in-house, using generic API consultancies unfamiliar with EHR certification processes, or FHIR platform vendors without SMART-specific EHR expertise — Peerbits delivers faster App Orchard approval, cross-EHR compatibility, and production-hardened token lifecycle management.
| Capability | Peerbits | Build In-House | Generic Consultancy | EHR Vendor PS | FHIR Platform Vendor |
|---|---|---|---|---|---|
| SMART App Launch v2.0 (EHR + Standalone + Backend) | ✓ All three | 2–4 months | EHR Launch only | Single EHR | Partial |
| Epic App Orchard Certification Management | ✓ 40+ approvals | 5–7 months | Limited exp. | ✓ | - |
| Multi-EHR (Epic + Cerner + Athena + eCW) | ✓ 4 platforms | 12+ months | 1–2 EHRs | 1 EHR only | Varies |
| Backend Services JWT + JWKS Library (4 languages) | ✓ Pre-built | 4–8 weeks | Custom build | - | Some |
| CDS Hooks + SMART Combined Build | ✓ Full | Separate efforts | Rarely | - | Partial |
| Inferno SMART Test Suite Pass Rate (1st submission) | 100% | ~40–60% | ~55–70% | ~70% | Varies |
| Token Lifecycle (refresh, expiry, re-auth) Handling | ✓ Production-grade | Manual | Basic | Partial | Framework only |
| Average App Orchard Approval Timeline | 8–10 Weeks | 5–7 Months | 4–6 Months | 3–5 Months | N/A |
MEASURED OUTCOMES
Across 95+ live SMART on FHIR applications deployed across Epic, Cerner, Athenahealth, and eClinicalWorks — these are the certification, performance, and delivery metrics that define Peerbits' SMART expertise.
95+
Across AI coding, prior authorization, risk scoring, patient engagement, CDR tools, and specialty clinical workflow categories.
40+
First-submission pass rate 90%+ — compared to the industry average first-submission rejection rate of 60–70% for teams without prior App Orchard experience.
8wks
From sandbox development start to App Orchard approval — vs. a 5–7 month industry average for teams navigating the process for the first time.
4
Epic, Oracle Cerner, Athenahealth, and eClinicalWorks — with platform-specific SMART libraries across normalization and launch context handling for each.
100%
Zero HL7 Inferno SMART App Launch test suite failures across all SMART app certifications — all three launch patterns tested and validated before submission.
<0.1%
Proactive token refresh at 80% TTL reduces auth failures during clinical sessions to under 0.1% of all SMART app sessions in production environments.
3
EHR Launch, Standalone Launch, and Backend Services — all three SMART App Launch 2.0 patterns implemented, certified, and in production use across client applications.
15yr
Peerbits has been building healthcare apps since before SMART on FHIR existed — including the FHIR predecessor frameworks (DSTU2 on FHIR DSTU2) in earliest EHR deployments.
From digital health startups navigating their first Epic App Orchard submission to health system IT teams embedding clinical AI inside PowerChart — Peerbits' SMART on FHIR work in production speaks for itself.
#clientspeak
Learn more about our processes from our clients
After a rigorous selection process, choosing Peerbits as our technology partner was the right choice. Peerbits is an innovative company with a team of talented, committed, and smart individuals. Thank you for helping us deliver world-class healthcare solutions.
Health Vector
READY TO BUILD?
In a 45-minute technical session, our SMART on FHIR engineering team will assess your current implementation, identify your App Orchard blockers, review your scope architecture, and give you a realistic path to production.
Book Free Assessment →Schedule a Live DemoSee how we've helped hospitals, clinics, and health systems solve real operational challenges with custom software.
Healthtech , AWS / Cloud ,
A healthcare startup struggled with increasing loads of data and manual infrastructure management as its business expanded. Peerbits successfully built cloud infrastructure using AWS for their system possessing auto-scaling, automated and more.
Healthtech ,
This is a native iOS app that helps to bridge the gap between the patients and healthcare providers. Patients can monitor their health on a regular basis and share the data with the doctors and healthcare professionals.
Healthtech , Chatbot ,
Remote patient monitoring app helps to bridge the gap between patients and healthcare providers. It tracks the vitals of the patients and sends it to the doctors.
SMART on FHIR is the open standard for launching clinical applications inside EHR systems — combining HL7 FHIR for data access with OAuth 2.0 for secure authorization. It enables apps to launch inside Epic, Cerner, and Athena with full patient and encounter context pre-loaded, without separate logins or manual data entry. ONC now requires all certified EHRs to support SMART App Launch v2.0.
EHR Launch embeds your app inside the EHR workflow — clinicians click it from within Epic or Cerner and it loads with patient context automatically. Standalone Launch is for patient-facing or provider-facing apps that open independently outside the EHR. Backend Services is for system-to-system access — pipelines, analytics, and server-to-server FHIR access without a user session. Most production deployments require at least two of the three.
Without prior experience, Epic App Orchard approval typically takes 5–7 months — with 60–70% of first submissions rejected for underdocumented scope justification, missing PKCE implementation, or non-compliant launch context handling. Peerbits has submitted and received approval for 40+ App Orchard applications, reducing the average timeline to 8–10 weeks with a 90%+ first-submission pass rate.
CDS Hooks is an open standard that fires clinical decision support services automatically at key EHR workflow moments — order-sign, patient-view, medication-prescribe. It works alongside SMART by passing the current patient context to your CDS service, which returns cards with suggestions, alerts, or app launch links directly inside the clinician's EHR workflow without requiring a separate app launch.
Each EHR vendor implements the SMART specification with proprietary extensions — different token endpoint behaviors, non-standard launch context parameters, and vendor-specific scope handling. An app that passes Epic's SMART conformance test may silently fail on Cerner. Peerbits maintains platform-specific SMART implementation libraries for Epic, Cerner, Athena, and eCW — normalizing divergent behaviors behind a single cross-EHR interface.
SMART Backend Services enables system-to-system FHIR access without a user session — used for ETL pipelines, analytics engines, and population health platforms. It requires asymmetric RSA or EC key pairs, JWT client assertions signed with the private key, JWKS URI publication for public key discovery, and system/* scope negotiation. Peerbits provides pre-built Backend Services auth libraries for Node.js, Python, Java, and .NET.
The cost depends on the number of launch patterns required, target EHR platforms, App Orchard certification scope, CDS Hooks integration, and whether Backend Services auth is needed. Most engagements go from sandbox to production in 8 weeks. Contact us for a scoping session — we'll map your launch pattern, scope model, and EHR targets before providing an estimate.
Have more questions?
Ask our expertsStay ahead with expert insights on healthcare technology, compliance, and digital transformation.
