Table of contents
- Why Epic & Cerner Integration Choices Matter
- Two Core Approaches: SMART on FHIR vs. Backend Systems Integration
- SMART on FHIR: Embedded Workflows, FHIR Calls, and EHR Uptime Constraints
- Backend Systems: 24/7 Persistent Integration and Independent Infrastructure
- SMART on FHIR vs. Backend Systems: Technical Comparison
- FHIR Data Access & Write-Back: What You Can (and Can’t) Read/Write
- AI Readiness: Why Integration Architecture Determines Whether AI Is Possible
- Decision Framework: Which Integration Approach is Right for Your Use Case?
- The Implementation Roadmap: Registering and Testing Your App
- FAQ: SMART on FHIR vs. Backend Systems for Epic & Cerner
Why Epic & Cerner Integration Choices Matter
If you’re deciding on SMART on FHIR vs backend integration for Epic & Cerner, you’re not really picking a “technology” — you’re picking an architecture that will shape clinician adoption, scalability, and what’s even possible for AI later.
Epic and Cerner continue to dominate the enterprise health systems landscape, powering a vast majority of large hospitals and health networks across the U.S. In most enterprise deals, they’re the two EHR platforms you’ll encounter first, and your integration path is often evaluated early in the buying process. For digital health companies selling into health systems, interoperability is the price of entry. Buyers expect your product to pull the right data at the right time, with the right audit trail, without breaking their procedures or creating security risks.
The real question usually isn’t “Can we integrate with Epic/Cerner?” You almost always can, in some form. What’s important is how you integrate, because the architecture you choose will determine:
- Clinical adoption rates: Will clinicians actually use your product in their daily workflows?
- Enterprise scalability: Will sales cycles move forward?
- Data depth and AI readiness: Can you support AI and analytics later?
In practice, most integration efforts fall into two core approaches: SMART on FHIR apps that launch within the EHR in the clinician’s workflow, or backend integration systems that run 24/7 outside Epic/Cerner and connect via APIs, feeds, and event mechanisms.
At Itirra, we help digital health teams deal with these trade-offs, mapping product requirements to integration patterns that actually work with Epic, Cerner, and real health system IT environments. Now let’s get concrete and practical.
Two Core Approaches: SMART on FHIR vs. Backend Systems Integration
Let’s define a clear distinction: SMART on FHIR and backend systems integration are not competing technologies. They’re different architectural patterns, each optimized for different problems. In practice, you’ll choose one as your starting point or implement both in a phased sequence.
SMART on FHIR apps are lightweight web applications launched directly from within the EHR. The clinician clicks a button on the patient chart; your app opens in a browser window and automatically receives context on which patient, encounter, and user triggered the launch. Your application then makes FHIR API calls back to Epic or Cerner to retrieve additional clinical data, display insights, and potentially write information back to the chart. The app is context-aware and session-based, and it primarily allows real-time clinical decisions. The most important thing is that SMART on FHIR apps only run when actively launched and rely entirely on the EHR being available.
Backend systems are independent services that run on your infrastructure. They pull data from Epic and Cerner through a mix of APIs, webhooks, HL7 v2 feeds, or FHIR queries. This approach helps store, normalize, and process data continuously, independent of any clinician session, a key difference from SMART on FHIR apps. Backend system architecture empowers always-on use cases, including health analytics, automated alerts, background workflows, data pipelines that feed AI models, and any feature that doesn’t need to occur in real time within the chart.
Consultant’s Tip: Many successful products implement both approaches: a SMART app for clinician-facing functionality, backend systems for data processing and analytics. The question isn’t “which one,” but “which first, and in what sequence?” If you’re planning that sequence across vendors and sites, this companion resource helps: how to plan a scalable FHIR integration roadmap for digital health products.
SMART on FHIR: Embedded Workflows, FHIR Calls, and EHR Uptime Constraints
SMART on FHIR is the most clinician-visible integration model. Here’s how it works in practice:
A clinician is reviewing a patient in Epic or Cerner and sees a button or link to your application (e.g., “Risk Calculator” or “Open Care Coordination Panel”). They click it. Your app opens, either in an embedded panel or a new window. Automatically, without the clinician having to log in again, your app receives context: the patient ID, the encounter, the logged-in user, and, in some cases, the reason for the launch (e.g., “the clinician clicked while writing an order”).
Inside your app, you can now call FHIR APIs to fetch whatever data you need: patient demographics, problems, medications, lab results, vital signs, recent notes, or upcoming appointments. You parse that data, run your logic, and display results or recommendations. If your workflow allows it, you can write back, creating a task, adding a note, or updating a flowsheet value.
Access is handled via OAuth, and your app only receives the scoped permissions the EHR grants for that user. This is also where teams get burned – these SMART on FHIR implementation pitfalls are worth pressure-testing against before you go live.
Upside: SMART on FHIR integration puts your application directly into the clinical workflow. When implemented well, it feels like a native part of Epic or Cerner – clinicians don’t perceive they’re using a “third-party app” at all.
Backend Systems: 24/7 Persistent Integration and Independent Infrastructure
A backend system is a separate service (or set of services) that continuously moves data between Epic/Cerner and your product, independent of whether a clinician has your app open.
What Backend System Integration Actually Means
You’re building your own infrastructure running on your servers or cloud platform. From there, it typically includes a stack of services like:
- Data synchronization services that pull patient information via FHIR APIs on schedules (every hour, nightly, etc.);
- HL7 v2 interface engines that consume ADT (Admission, Discharge, Transfer) messages or ORU (Observation Result) lab feeds;
- Webhook consumers that receive real-time notifications when specific events occur;
- Analytics databases that normalize and store clinical data for reporting and AI;
- Notification services that send alerts to clinicians via SMS, email, or in-app messaging.
Upside: The backend system infrastructure runs continuously and powers automation, analytics, and cross-site workflows, regardless of whether any clinician has Epic or Cerner open.
SMART on FHIR vs. Backend Systems: Technical Comparison
The right choice depends on whether your product needs in-workflow UX, always-on processing, or both.
SMART on FHIR runs inside the clinician’s workflow. It’s excellent for low-latency, context-aware experiences where responsiveness and adoption matter most. It’s also constrained by the fact that it runs within a session and the EHR’s operational realities.
Backend system runs outside the EHR. It’s better for persistence, historical depth, and asynchronous workflows. It’s heavier to build because you must operate it like a production system: secure it, monitor it, scale it, and make it resilient.
Let’s compare technical dimensions that matter for decision-making:
| SMART on FHIR | Backend Systems | |
|---|---|---|
| Where It Runs | Embedded in EHR, clinician-initiated browser session | Independent 24/7 infrastructure |
| EHR Dependency | Complete (unavailable if EHR is down) | Partial (can cache and queue during outages) |
| Data Access | Current patient, session-limited | Full historical context |
| Best For | Real-time decision support, in-chart tools | Analytics, always-on monitoring, AI/ML |
| Complexity to deploy | Moderate (web app + OAuth/FHIR) | High (full infrastructure stack) |
| UX Impact | Immediate and visible. Clinicians see value in workflow, no context switching. | Invisible by default. Requires separate UI or notifications to drive awareness |
It’s a common occurrence when teams try to force everything into SMART and then struggle with persistence and scale. Conversely, trying to build backend-only and ignoring in-workflow UX often leads to struggles with adoption.
Contact us to find the best-fitting option for you: SMART on FHIR, backend systems, or a hybrid approach.
FHIR Data Access & Write-Back: What You Can (and Can’t) Read/Write
FHIR looks standardized, but in real Epic and Cerner environments, what you can access depends heavily on site configuration, scopes, and governance. You can’t assume the standard spec translates to every implementation. Here’s what you can realistically access:
What You Can Read
Most Epic and Cerner implementations support reading:
- Patient demographics – name, date of birth, identifiers, contact information;
- Clinical data – conditions, medications, allergies, procedures, lab results, vital signs;
- Care events – encounters, appointments, care team assignments;
- Documentation – diagnostic reports and document references/attachments (with varying levels of access).
What you can’t assume is that FHIR will give you everything a clinician can see in the chart with the same fidelity. Full note text access varies widely; scheduling data is often partial; and pulling deep history in real time can run into paging, performance, or governance limits, so you’ll likely need caching or bulk processing for anything longitudinal.
What You Can Write
Write-back is more constrained. Typically supported are:
- Observations – custom measurements, flowsheet values;
- Documents – attaching external reports or summaries to the chart;
- Tasks – creating to-do items or care team notifications;
- Care plan entries – possible in select implementations.
You generally shouldn’t plan on broad write access by default. Orders and edits to clinician documentation typically trigger stricter review (and may require non-FHIR pathways), and write scopes vary significantly by site, even within the same vendor. Treat write-back as a phased milestone, not a day-one assumption.
Consultant’s Tip: Your integration architecture determines what’s feasible in production, not what the FHIR specification theoretically allows. Plan based on what’s actually implemented at your target health systems.
AI Readiness: Why Integration Architecture Determines Whether AI Is Possible
If you have AI ambitions, your integration architecture matters enormously.
Why SMART-Only Integration Limits AI
AI models call for substantial training data – ideally thousands of patient records with longitudinal histories. A SMART on FHIR app that only accesses data during active clinician sessions can’t efficiently assemble these datasets. Even if you tried to pull comprehensive histories via FHIR during each launch, you’d hit rate limits and create unacceptable latency.
Raw FHIR resources are JSON documents with varying structures, optional fields, and inconsistent coding systems. However, AI models need normalized, structured data in formats optimized for machine learning. Without a backend pipeline to normalize these into analytics-ready schemas, you’re stuck with data too messy to train on.
There’s, however, a trade-off you’ll meet: SMART apps excel at deploying AI insights to clinicians during encounters. But they are unabale to generate those insights – you can’t train models on session-only data, accumulate longitudinal datasets, or perform the data work AI requires.
Backend Systems Are Where AI Happens
A backend integration is the foundation of AI readiness. Here’s why:
Normalized schemas and vocabularies: FHIR is standard, but implementations vary. Your backend normalizes data to a consistent schema, maps local codes to standards such as LOINC, and ensures that, for example, “glucose” in one EHR matches “glucose” in another. This is invisible work, but it’s a prerequisite for training.
Historical context and temporal modeling: Your backend stores complete patient timelines, rather than just the latest state. You can see how a patient’s condition evolved, when interventions were implemented, and the outcomes. This is essential for any predictive model.
Consent-aware design and Protected Health Information (PHI) minimization: If you’re training a model at scale across sites, you must comply with consent and privacy directives. Your backend can enforce these filters at query time, confirming that only consented data is included in training.
Staging environments for model validation: You can test models with your normalized data before they ever touch production, which is much safer than embedding untrained logic in a SMART on FHIR app.
Key Lesson: A SMART-only architecture forces you to either:
- call your backend from within the app (which reintroduces the latency and EHR dependency problems), or
- not do AI at all.
If you’re a startup building toward AI readiness, check out this guide: FHIR integration consulting for healthcare startups.
Decision Framework: Which Integration Approach is Right for Your Use Case?
If your primary value is real-time clinician decision support in the chart: Start with SMART on FHIR.
Examples: order set helpers, risk scores at triage, documentation assists, drug interaction checks. The clinician sees value immediately, and the adoption rate is high.
If your primary value is analytics, monitoring, notifications, or cross-site workflows: Opt for a backend system from day one.
Examples: cohort identification, readmission prediction, population health dashboards, multi-hospital care coordination. You’ll need normalized data at scale – it performs well in the result, but be ready for a longer setup process.
If you’re uncertain but suspect you’ll need both: Consider a phased approach. Build a backend foundation first (it takes longer and is more complex), then add a SMART app for high-value workflows. This is more efficient than building SMART first and then adding a backend retroactively.
Product-specific guidance:
- Simple point-of-care tools (calculators, guidelines, order entry helpers) → Go with SMART on FHIR
- In-chart clinician productivity tools (documentation helpers, chart review accelerators) → Go with SMART on FHIR
- Real-time clinical decision support → Go with SMART on FHIR
- Remote patient monitoring (RPM), telehealth, or chronic disease management → Go with Backend Systems
- Care coordination or discharge planning → Go with Hybrid. Backend handles background cohort building; SMART app handles point-of-care coordination
- AI/ML-powered clinical decision support → Go with Hybrid. Backend for data + SMART for delivery
Consultant’s Tip: Kick off with a question: “How many EHR instances do we need to support?” If you’re targeting 1–2 pilot health systems, SMART alone is faster. If you’re targeting 20+ systems, assume you’ll need a backend to normalize across vendor differences and scale operations.
The Implementation Roadmap: Registering and Testing Your App
Step 1: Clarify Workflows and Integration Scope
Start by documenting exactly which workflows you support, the data you need to read and write, and whether you require real-time or asynchronous processing.
Step 2: Choose SMART, Backend, or Hybrid Architecture
Based on your workflows, make the architectural decision. If you’re uncertain, prototype both approaches in sandbox environments before committing.
Step 3: Register with Epic/Cerner and Obtain Credentials
For SMART on FHIR apps, vendor registration gets you sandbox access and client credentials. For backend system integrations, plan for a health system security review, contracts (often including a BAA).
Step 4: Implement FHIR/SMART Flows Plus Non-FHIR Feeds
Build your integration code – OAuth flows, FHIR API calls, data parsing and normalization, error handling, and logging. For backend systems, implement HL7 v2 parsers, webhook consumers, or batch data transfer mechanisms as needed.
Step 5: Test in Sandboxes and Pilot Sites
Sandbox testing validates basic functionality but won’t catch site-specific issues. Pilot site testing is essential: pick 1-2 friendly customer sites willing to test in non-production environments before full go-live. Test functional workflows, performance under realistic load, and security controls.
Step 6: Go-Live with Monitoring and Rollback Plans
Launch to production with comprehensive monitoring (API latency, error rates, data quality checks) and clear rollback procedures. Never deploy integration changes on Fridays or before holidays.
Step 7: Iterate and Extend to New Sites
Use learnings from initial deployments to refine your integration patterns. Build runbooks for common issues. Standardize configuration management so that deploying to new Epic or Cerner sites becomes repeatable.
FAQ: SMART on FHIR vs. Backend Systems for Epic & Cerner
SMART on FHIR is an EHR-launched app: it runs inside Epic or Cerner during an active clinician session and pulls data via FHIR APIs in real time. Backend integration runs outside the EHR as always-on services that sync, normalize, and process data continuously using a mix of FHIR, HL7 v2 feeds, webhooks/events, and other mechanisms.
It depends on your use case. Choose SMART on FHIR if you need real-time, in-workflow clinical decision support with immediate clinician visibility. Choose backend systems if you need 24/7 monitoring, analytics, cross-site workflows, or AI/ML capabilities. Most mature products eventually implement both in a hybrid approach.
SMART on FHIR typically has a faster time-to-value (4–8 weeks to sandbox validation) because you’re building a lightweight web app. Backend systems take longer (3–6 months) because they require full infrastructure setup, security reviews, and production monitoring.
Backend systems handle continuous ingestion, normalization, and automation (plus the data foundation for analytics and AI). A SMART on FHIR app then surfaces the right information inside the clinician workflow and captures user actions (accept/reject/confirm) for traceability. This is a common pattern for care coordination and AI-assisted decision support.
SMART on FHIR uses OAuth 2.0. When a clinician launches your app from the EHR, they’re automatically authenticated – no separate login needed. Your app receives a scoped access token that limits what data you can read based on the clinician’s permissions.
Not effectively. SMART apps only access data during active clinician sessions, which doesn’t provide the longitudinal, historical datasets AI models need. You’ll hit rate limits and experience unacceptable latency if you try. AI requires a backend infrastructure to assemble and normalize data at scale.
If your first enterprise deal depends on integration, if you need write-back, if you’re targeting multiple sites quickly, or if AI readiness is part of your roadmap, specialist help usually pays off. The value is less “extra hands” and more avoiding rework – choosing the right architecture early, aligning scopes/governance, and building patterns you can reuse across customers.