SMART on FHIR: What It Is, When You Need It, and How Long It Takes

There is a pattern that plays out repeatedly in health IT sales cycles at the scaleup stage.

Your product works well. Your existing customers are happy. You have a strong pipeline of hospital systems and clinic groups that want to buy. Then the CIO or IT director asks one question: "How does this integrate with our Epic environment?"

If your answer is "we are working on it" or "we support HL7 v2 feeds," the deal slows down or stops entirely.

The expectation in 2026 from enterprise health systems across the US, UK, and increasingly the GCC is SMART on FHIR. It has become the standard for how third-party clinical applications connect to EHR platforms. Products that do not support it are increasingly described internally by hospital procurement teams as data silos, and data silos do not get purchased at scale.

This guide explains what SMART on FHIR is, when your product actually needs it, and what the realistic timeline looks like so you can plan and execute without surprises.

What Is SMART on FHIR?

SMART on FHIR is a combination of two separate standards that work together.

FHIR (Fast Healthcare Interoperability Resources) is the data standard. It defines how health data, patient demographics, clinical notes, medications, lab results, appointments, and more, is structured and exchanged between systems. FHIR R4 is the current widely adopted version. FHIR R5 is available and beginning to be adopted, but R4 remains the standard for most EHR integrations in 2026.

SMART (Substitutable Medical Applications, Reusable Technologies) is the security and authorisation layer on top of FHIR. It defines how an application requests access to FHIR data, how the EHR authenticates and authorises that request, and how the application launches within or alongside the clinical workflow.

Together, SMART on FHIR gives your application a standardised, secure way to:

• Launch from within the EHR interface (EHR-embedded launch)
• Launch standalone and connect to the EHR's FHIR server (standalone launch)
• Request specific scopes of patient or user data
• Receive and use OAuth 2.0 tokens to read and write FHIR resources

The framework was developed at Boston Children's Hospital and Harvard Medical School and has been formally adopted by Epic, Cerner (Oracle Health), AthenaHealth, and most other major EHR vendors. The US federal 21st Century Cures Act, which came into effect in 2021, mandated FHIR-based API access for certified EHR systems, which made SMART on FHIR the practical implementation path for third-party integrations across the entire US market.

SMART on FHIR in One Table

When Does Your Product Actually Need SMART on FHIR?

Not every health IT product needs full SMART on FHIR implementation. The requirement depends on what your product does and how it fits into clinical workflows. Here is a practical guide:

There are three main SMART on FHIR launch patterns, and choosing the right one matters for your architecture:

EHR Launch: The EHR initiates the app launch. A clinician clicks a button inside Epic or Cerner, your app opens with the current patient's context already loaded, including patient ID, encounter ID, and user details. This is the most common pattern for clinical workflow tools.

Standalone Launch: Your app initiates the connection independently. A patient or provider opens your application and connects to their EHR to retrieve or push data. Used for patient portals, remote monitoring, and analytics platforms.

Backend Services (SMART Backend Services): Used for server-to-server communication where there is no human user in the loop. Common for bulk data exports, population analytics, and automated data pipelines. Uses asymmetric key authentication rather than user-facing OAuth flows.

Technical Requirements Your Team Needs for SMART

SMART on FHIR integration has several technical components that each carry meaningful implementation complexity. Here is what your engineering team needs to build or verify:

1. OAuth 2.0 and OpenID Connect Implementation

Your application must implement OAuth 2.0 authorisation code flow correctly. This includes:

• Constructing the authorisation request with the correct SMART scopes
• Handling the redirect and authorisation code exchange
• Managing access token and refresh token lifecycles
• Handling token expiry gracefully without disrupting user sessions
• Storing tokens securely and never exposing them in client-side code or logs

This sounds straightforward if your team has built OAuth flows before. The SMART-specific complexity is in the scope definitions and the launch context parameters that EHR systems pass during the token exchange.

2. FHIR Resource Implementation

Your product needs to correctly read and write the FHIR resources relevant to its function. Common resources by product type:

The critical technical requirement here is not just reading these resources but validating them correctly. FHIR resources from real EHR systems frequently contain optional fields, extensions, and implementation-specific variations. Your application must handle missing fields gracefully and not break when a resource arrives without an element your code assumed would always be present.

3. EHR-Specific FHIR Profiles

Epic, Cerner, and AthenaHealth each publish their own FHIR implementation guides that define how they implement FHIR R4. These are called conformance profiles, and they matter significantly.

Epic's FHIR API, for example, uses Epic-specific extensions for certain resources, has specific rules about which search parameters are supported, and requires specific launch parameters for EHR-embedded apps. Cerner's implementation has its own variations. Building to base FHIR R4 without reviewing the target EHR's implementation guide produces integration failures that look confusing until you realise the EHR vendor simply implements the standard differently in specific areas.

4. SMART App Launch 2.0

SMART App Launch 2.0 was finalised in 2021 and introduced several important changes from the original specification:

• Granular scopes replacing the older wildcard scope model
• PKCE (Proof Key for Code Exchange) as a required security control
• Asymmetric client authentication for backend services
• Token introspection support

Most major EHR vendors now require or strongly prefer SMART App Launch 2.0. If your team built an initial SMART integration before 2022, it is worth reviewing whether your implementation meets the 2.0 specification.

How Long Does SMART on FHIR Integration Take?

This is the question CTOs ask most and get the least straight answer to. Here is an honest breakdown by phase:

Total realistic timeline from start to first production go-live: 5 to 12 months.

The longest and most unpredictable phase is EHR vendor review and approval. Epic's App Orchard review process, for example, involves a formal application, a technical review, a security review, and in many cases multiple rounds of feedback. Teams that submit an incomplete application or fail the security review add weeks to the process.

According to data published by the HL7 FHIR community in 2023, the average time from starting an Epic SMART on FHIR integration to first production deployment across a sample of 40 health IT vendors was 8.3 months. Teams with prior FHIR experience averaged 5.5 months. Teams without it averaged over 11 months.

Plan accordingly.

What CTOs and VPs of Engineering Get Wrong

Mistake 1: Treating EHR sandbox approval as a short final step.

The EHR sandbox and vendor review phase is often the longest single phase in the entire integration project. Teams that plan for two weeks and experience twelve are not unusual. Apply for sandbox access much earlier than feels necessary.

Mistake 2: Building to base FHIR R4 without reading the EHR's implementation guide.

Every major EHR publishes a FHIR implementation guide that documents their specific profiles, extensions, and supported search parameters. These guides run to hundreds of pages. Teams that skip them and build to the base specification produce integrations that fail in ways that take time to diagnose.

Mistake 3: Underscoping FHIR resource handling.

Production EHR data is messier than test data. Resources arrive with missing optional fields, unexpected extensions, and edge cases your test environment never produced. Applications that assume clean, complete FHIR resources break in production with real patient data.

Mistake 4: Not planning for write-back complexity.

Many integrations start as read-only and later require writing data back to the EHR. Write access in SMART on FHIR requires additional scopes, additional vendor approval, and additional security review. Retrofitting write-back capability into a read-only architecture after the initial integration is live adds significant time and rework.

Mistake 5: Missing PKCE in the OAuth implementation.

SMART App Launch 2.0 requires PKCE. Some teams implementing SMART for the first time miss this, which causes failures specifically when connecting to EHR environments that enforce 2.0 compliance strictly.

Pre-Integration Readiness Checklist

Before starting your SMART on FHIR integration or approaching an EHR vendor partnership, work through these:

Conclusion

SMART on FHIR is not a future consideration for health IT scaleups. It is the current standard for EHR integration, and it is already the deciding factor in enterprise procurement conversations across the US and UK markets.

Products that support it properly are positioned to integrate with any major EHR system, expand into new health system accounts, and win deals that data-silo products cannot. Products that do not support it, or that support an incomplete or outdated version of it, are paying a visible cost in lost enterprise deals every quarter.

The integration is achievable. The timeline is manageable when planned honestly. The complexity is real but not unusual for engineering teams with enterprise software experience.

The most important thing you can do right now is assess where your current architecture stands relative to SMART App Launch 2.0, identify which EHR vendors matter most to your pipeline, and start the vendor access applications immediately. The sandbox and review timelines are the longest phase, and they do not shorten regardless of how fast your engineering team moves.

Start earlier than you think you need to. The EHR vendor review calendar does not respond to your sales deadlines.