EHR-embedded apps
Provider-facing apps launched in-context from Epic, Cerner, and athenahealth.
SMART on FHIR
SMART on FHIR App Development
We build SMART on FHIR apps that launch inside Epic, Cerner, and athenahealth: EHR launch contexts, scoped OAuth 2.0 access, and FHIR R4 data flows, HIPAA-ready and correctly scoped from day one.
FHIR R4OAuth 2.0 ScopesEHR Launch ContextApp Orchard
Trusted by global innovators
What SMART on FHIR app development actually involves
SMART on FHIR is the open standard that lets one healthcare app run inside many EHRs. It adds a launch and authorization framework to FHIR: the EHR launch passes patient, user and system context, and OAuth 2.0 grants scoped access (patient/*, user/*, system/*) to the FHIR endpoints the app needs, across Epic, Oracle Health (Cerner) and athenahealth.
The work is in launch and scopes: EHR versus standalone launch, OAuth 2.0 scope negotiation and refresh, OpenID Connect identity and each EHR's marketplace review. We design the launch flow and scope model first, then build and register the app so it clears review.
What SMART on FHIR is
SMART on FHIR is how apps run inside the EHR
SMART on FHIR is an open standard that lets healthcare apps securely connect to EHRs using FHIR data and OAuth 2.0 authorisation, so a single app can run across systems like Epic, Cerner, and athenahealth without custom point-to-point work.
It layers an application launch and authorisation framework on top of FHIR: the EHR launches your app with patient, user, and system-level context, and grants it scoped access to the FHIR endpoints it needs.
SMART on FHIR app architecture
A blueprint for an EHR-embedded SMART app: launch context, OAuth 2.0 scope negotiation, FHIR R4 resource access, and the consent, terminology, and monitoring layers production needs.
SMART on FHIR APIs & standards we work with
We name the exact launch model and scopes up front, because that determines what the app can do inside the chart.
EHR launch + OAuth scopes
EHR and standalone SMART launch with OAuth scopes (patient/*, user/*, and system/*), plus launch context, token refresh, and OpenID Connect identity for apps that run inside Epic, Cerner, and athenahealth.
FHIR R4 resource access
Scoped read/write against the EHR's FHIR R4 API (Patient, Encounter, Observation, MedicationRequest, DocumentReference) with US Core conformance.
App Orchard & marketplace listing
Registration and review through Epic App Orchard, Cerner Code, and equivalent EHR marketplaces so the app reaches real sites, not just a sandbox.
CDS Hooks & in-workflow guidance
Decision-support surfaced in the clinician's workflow via CDS Hooks and SMART apps, not disruptive pop-ups.
Wearable & device data
Consented pipelines that bring Bluetooth and IoT device vitals (Fitbit, Dexcom, Apple Health) into the SMART app as FHIR Observations.
Consent, PHI & observability
Patient-consented data flows, PHI-aware logging, and app health monitoring so access stays scoped, audited, and reliable in production.
Where it runs
SMART on FHIR use cases
Patient engagement apps
Patient-authorised apps with access to their own clinical data across systems.
Clinical decision support
In-workflow guidance surfaced through SMART apps and CDS Hooks.
Specialty workflows
Specialty-specific modules tailored to clinical logic and care plans.
Remote monitoring
Wearable and device vitals flowing into SMART apps via consented pipelines.
Third-party marketplaces
Apps distributed through Epic App Orchard and equivalent EHR marketplaces.
Bridge every system across your care ecosystem
SMART on FHIR gives your applications a standards-based way to connect with EHRs, devices, and third-party services, without brittle point-to-point integrations.
FHIR R4
Resources read and written through each EHR's API
OAuth 2.0
Scoped access the patient or clinician approves
BAA
Signed before any PHI flows
Compliance-First Healthcare App Development Services Backed by Global Standards
15-Minute Scoping Call01
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
02
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
03
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
04
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
05
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
06
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
07
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
08
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
09
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
AI inside the EHR
How do AI tools run inside the EHR?
AI tools run inside the EHR through one of three standard patterns: a SMART on FHIR app the clinician opens, a CDS Hooks service returning workflow cards, or a backend services app with no user. In all three, the AI drafts and the clinician decides.
| Launch pattern | What the AI can read | How results reach the clinician | Write-back rule | Transparency information |
|---|---|---|---|---|
| SMART EHR launch | The patient and encounter in context, limited to the scopes granted at launch | Inside the app window in the chart, beside the record | Drafts only: the clinician reviews and signs before anything is filed | Intended use, intended users, output type and known limits, shown in the app and supplied to the health system |
| CDS Hooks service | The hook context and prefetch data the EHR sends, such as the chart being opened or the order being signed | A card with a summary, suggestions or a link that launches a SMART app | Suggestions the clinician accepts or dismisses; nothing changes without that action | Source attributes the health system can record against the intervention in its certified EHR |
| Backend services app | Data for a defined group of patients through system scopes, with no user signed in | Results placed on a worklist or queue a clinician reviews later | Never files to the chart directly; output waits for clinician sign-off | The same source attributes, plus how the model was validated externally and how it is monitored |
ONC certification criterion 45 CFR 170.315(b)(11) requires certified EHRs to support source attributes for Predictive Decision Support Interventions, such as intended use, intended users, cautioned out-of-scope uses, known risks and external validation. We write these for your AI tool.
Standards we build against
SMART on FHIR standards
FHIRSMARTOAuth2OIDCHIPAASOC 2
Our Process
How we ship a SMART on FHIR app
Launch and scope design, build, and marketplace review run as parallel tracks so the app reaches real EHR sites on a predictable timeline.
1.
Discovery & Scope
We confirm target EHRs, EHR vs standalone launch, the OAuth 2.0 scopes and FHIR resources the app needs, and the marketplace path before any code.
Launch-first
2.
Sandbox & App Registration
We register the SMART app, provision sandbox credentials, and validate launch context, scope approval, and token refresh against the vendor's test data.
Sandbox-gated
3.
Build & Test
We build the embedded app, scoped FHIR request orchestration, US Core mapping, and consent flows, validated with partner-assisted and security testing.
Scope-tested
4.
Go-Live & Monitoring
Marketplace review, phased production rollout, and app health monitoring with alerting as EHR sites enable the app.
Observable in production
Build vs buy vs aggregate
Evaluate your integration path
A direct breakdown for CTOs and integration engineers weighing build vs. buy vs. aggregation.
| Criteria | Aggregator | Build it yourself | Agnotic |
|---|---|---|---|
| EHR coverage | Only the EHRs the aggregator already connects | Each EHR app program and API learned by your team | Built for the EHRs you need, against each vendor's published FHIR API |
| Timeline | Set by the aggregator's onboarding queue | Set by your team's capacity and each EHR's app review | Agreed after scoping, per EHR and vendor app review |
| Compliance | Partial: you inherit the aggregator's controls and gaps | Full burden on your security team | HIPAA safeguards built in, with evidence your auditors can review |
| Data ownership & portability | Vendor holds your data, hard to exit | You own it: migration cost is high | You own all data; export any time |
We engineer for the operational reality, not the demo.
Featured case study
Read Case StudyLera Health: compliant health platform
Related proof of app-layer delivery: for Lera Health we built a patient experience and privacy-first data layer end to end, with consent-aware, scoped data access, the same foundation an EHR-embedded SMART app requires.
Frequently Asked Questions
It depends on the launch model, the scopes and how many EHRs you target, and each EHR vendor's app review adds time no developer controls. We give you a timeline after the scoping call and plan the review steps in from the start so they don't surprise you.
Cost tracks the number of EHR targets, the FHIR resources and scopes involved, and whether marketplace certification is required. A focused app typically starts in the mid five to low six figures. We scope against your targets and share a range in a discovery call.
Production SMART apps generally require registering in each EHR's developer program (Epic App Orchard, Cerner Code) and passing app and security review before they run at real sites. We handle registration and prepare the app to clear review.
Yes. We bring Bluetooth and IoT device vitals (Fitbit, Dexcom, Apple Health) and telehealth data into the SMART app through HIPAA-compliant, patient-consented pipelines as FHIR Observations and Encounters.
It can if the app holds write scopes, but we do not build it that way. AI output is saved as a draft or a suggestion, and a clinician reviews and signs it before it becomes part of the record, so the clinician stays accountable for what is filed.
Yes. PHI encryption, audit logging, scoped access, and patient-consented data flows are built in from day one. We support FHIR R4 and SMART launch across Epic, Cerner, athenahealth, and other major EHR platforms.
Ready to connect your systems with SMART on FHIR?
See how SMART on FHIR apps can bridge your EHR, devices, and clinical workflows, mapped to your systems before the call ends.
contact@agnotic.com
Partnerships
contact@agnotic.com