SMART on FHIR launch: how Epic, Oracle Cerner, MEDITECH, athena, and NextGen actually do it

Substitutable Medical Applications and Reusable Technologies (SMART) on FHIR launch is the OAuth 2.0 based handshake that lets a third-party clinical app open inside an EHR, receive a patient context token, and call FHIR APIs with scoped permissions. Epic, Oracle Health (Cerner Millennium), MEDITECH Expanse, athenaOne, and NextGen all support it, but the marketplace, sandbox URL, framework version, and backend services profile differ in ways that change the build timeline. This article documents each EHR's current 2026 implementation so procurement and engineering leads can plan before they sign.

SMART on FHIR in one paragraph

SMART on FHIR is an open specification published by HL7 (Health Level Seven International) that defines how a clinical app authenticates against an EHR and reads or writes FHIR resources. The current version is the SMART App Launch Framework 2.0.0, released by HL7 in 2022 and now the baseline for the ONC HTI-1 Final Rule certification criteria adopted by the Office of the National Coordinator for Health IT in January 2024. SMART defines two launch modes. EHR-launch starts inside the clinician's EHR session, where the EHR passes a launch parameter and an issuer URL to the app, which then completes an OAuth 2.0 authorization code flow with PKCE. Standalone-launch starts outside the EHR, typically from a patient portal or a mobile app, and the app discovers the FHIR server through the .well-known/smart-configuration document. Scopes follow the pattern patient/Observation.read, user/Patient.read, launch/patient, offline_access, openid, fhirUser, with v2 adding finer-grained controls like patient/Observation.rs (read and search) and resource-level constraints expressed as FHIR search parameters. The full specification lives at hl7.org/fhir/smart-app-launch. The Argonaut Project, the implementer collaborative that drove the original SMART on FHIR rollout across Epic, Cerner, MEDITECH, athena, and Allscripts between 2014 and 2019, maintains the conformance test suite that most EHR sandboxes publish their results against.

For procurement teams reading this, the practical implication is that SMART on FHIR 2.0.0 conformance is now a hard procurement criterion for any clinical app deployed in a US hospital, ambulatory clinic, or payer organization. The Cures Act information-blocking rules administered by ONC penalize EHR vendors and provider organizations that block standards-based API access. CMS-0057-F, the CMS Interoperability and Prior Authorization Final Rule, requires impacted payers (Medicare Advantage organizations, Medicaid managed care plans, state CHIP agencies, qualified health plan issuers on the federally-facilitated exchanges) to expose Patient Access, Provider Access, and Payer-to-Payer APIs over SMART on FHIR by January 1, 2027 for the API requirements (the prior authorization decision timeframes took effect January 2026). That deadline is what is pulling SMART on FHIR build work forward in the 2026 procurement cycle.

The EHR-by-EHR comparison table

EHRApp marketplaceSandbox URLLaunch framework versionBackend services authNotesEpicEpic on FHIR + Showroom (formerly App Orchard, rebranded via Connection Hub in 2023)fhir.epic.com (open sandbox with sample patients Camila Lopez, Derrick Lin, Desiree Powell)SMART App Launch 2.0.0, plus SMART Backend Services with JWT client assertion (RS384 or ES384)Supported. App registers a public key (JWKS URL or static JWKS) at fhir.epic.com, then exchanges signed JWT for an access token at the token endpoint.Production deployment requires customer-specific endpoints. Epic publishes one OAuth endpoint per customer organization, surfaced through the open.epic.com endpoint directory.Oracle Health (Cerner Millennium)code.oracle.com/health (formerly code.cerner.com)fhir-ehr-code.cerner.com/r4 and fhir-myrecord.cerner.com/r4SMART App Launch 2.0.0 on the R4 endpoints; legacy DSTU2 endpoints remain for older deploymentsSupported via SMART Backend Services with asymmetric JWT auth. Registration handled through the Oracle Health developer console.Oracle completed the Cerner rebrand in 2023 but kept the developer portal URLs operational. Sandboxes split between provider-facing (fhir-ehr-code) and patient-facing (fhir-myrecord) endpoints.MEDITECH ExpanseMEDITECH Greenfield Workspacegreenfield.meditech.com sandbox with a published FHIR R4 endpointSMART App Launch 1.0.0 supported across the install base, 2.0.0 supported on Expanse releases from 2023 forwardBackend services supported on Expanse R4 endpoints; older MAGIC and Client/Server platforms do not expose system-to-system FHIR.MEDITECH posts the developer agreement and sandbox keys through the Greenfield portal. Production endpoints require coordination with the hospital's MEDITECH account team.athenaOneathenahealth Marketplace (developer portal at developer.athenahealth.com)api.preview.platform.athenahealth.com for the FHIR R4 sandboxSMART App Launch 2.0.0 on the FHIR R4 endpoints; the legacy athenaNet API is separate and not SMART basedBackend services supported through the More Disruption Please (MDP) developer program with asymmetric JWT registration.athena gates production access on a signed partnership agreement and a security review before listing in the Marketplace.NextGen HealthcareNextGen Connect Marketplace and the NextGen Developer Portalfhir.nextgen.com sandbox with sample organizationsSMART App Launch 2.0.0 on R4; supports both EHR-launch and standalone-launchBackend services supported through the NextGen Connected Health Platform with JWT client assertion.NextGen requires a partner agreement before publishing in Connect Marketplace. Sandbox access is self-serve through the developer portal.eClinicalWorkseClinicalWorks Developer Portal (developer.eclinicalworks.com)Sandbox available on request through the developer portalSMART App Launch 1.0.0 across most production deployments; 2.0.0 conformance is partial as of 2026Backend services support is limited compared with Epic and Oracle Health. Most integrations still rely on the EHR-launch flow.SMART maturity on eClinicalWorks lags the other five vendors. Plan extra integration time and validate scope coverage early.

Where the EU EHRs are in 2026

European EHRs sit on a different timeline because the European Health Data Space (EHDS) Regulation entered force in March 2025, with the EU EHR Exchange Format (EEHRxF) certification mandatory for new EHR deployments starting 2029. Dedalus, the largest EU EHR vendor by hospital count, runs ORBIS in Germany and DXC Care Suite (acquired from DXC Technology in 2020) in France, Italy, and Spain. Dedalus published a FHIR R4 facade in 2023 and supports SMART App Launch 1.0.0 on its newer deployments, with 2.0.0 conformance being added through the EHDS certification track. The Bundesinstitut fuer Arzneimittel und Medizinprodukte (BfArM) in Germany maintains the gematik specifications that Dedalus and CGM must conform to for the German Telematikinfrastruktur, and those specifications increasingly reference SMART on FHIR as the API access pattern.

CompuGroup Medical (CGM), headquartered in Koblenz, runs CGM CLINICAL in Germany and Austria and exposes FHIR R4 through the CGM eHealth platform, with SMART App Launch 1.0.0 supported. InterSystems TrakCare, used by NHS trusts in the UK, the Health Service Executive in Ireland, and Italian regional health authorities, supports SMART App Launch 2.0.0 natively because InterSystems also maintains IRIS for Health, the FHIR server many of the EHDS national pilots use. EU buyers should also note that ENISA (the European Union Agency for Cybersecurity) published the 2024 Threat Landscape for Health which identified OAuth misconfiguration as a recurring incident category in EU hospital networks. That guidance shapes the security review checklist for any SMART on FHIR build going into an EU public hospital. For UK deployments specifically, the NHS England Digital team publishes the NHS Login OAuth 2.0 profile which extends SMART on FHIR with NHS-specific identity assurance levels (P5, P9) that any patient-facing app on NHS infrastructure must implement on top of the standard SMART flow.

The MHRA (Medicines and Healthcare products Regulatory Agency) in the UK and the EMA (European Medicines Agency) for the EU treat SMART on FHIR apps that influence clinical decisions as software as a medical device under the UK MDR 2002 (as amended) and the EU MDR 2017/745 respectively. Any payer or established healthcare company building a SMART app that scores risk, recommends prior-authorization decisions, or generates differential diagnoses needs to map the SMART build to the medical-device conformity assessment route before scoping the engineering work. The ISO 13485 quality management system applies if the app is a Class IIa device or higher.

The 5 most common SMART launch failures

What about backend services auth (system-to-system, no clinician launch)?

SMART Backend Services is the profile for population-level data exchange where no clinician is present at launch. The HL7 specification at hl7.org/fhir/smart-app-launch/backend-services.html defines a flow where the app holds an asymmetric key pair, registers the public key (or a JWKS URL) with the EHR, and signs a JWT client assertion to obtain an access token. The JWT carries iss and sub equal to the client_id, an aud claim equal to the token endpoint URL, and a jti for replay protection. The access token grants system-level scopes like system/Patient.read or system/Observation.rs. This is the profile that powers CMS-0057-F bulk data exchange for prior authorization (effective January 2026 for impacted payers under the CMS Interoperability and Prior Authorization Final Rule) and the FHIR Bulk Data Access (Flat FHIR) export API. The difference from EHR-launch is that there is no patient context token, no launch parameter, and no human in the loop. Hosting the JWKS endpoint on a stable, TLS-protected URL is a hard prerequisite. Epic, Oracle Health, athenaOne, and NextGen all require the JWKS URL to be reachable from their token endpoints during registration validation.

Procurement-readiness checklist before you commit to a SMART on FHIR build

Where Life Value sits in this

Life Value builds SMART on FHIR apps from scope-design to production launch for healthcare ISVs, established healthcare companies, public health systems, and private hospital networks. Our practice covers Web App Development (the clinician-facing SMART app that opens inside Epic Hyperspace, Oracle Cerner PowerChart, or MEDITECH Expanse), Mobile App Development (standalone-launch apps for patient-facing and clinician-facing workflows on iOS and Android), and Custom AI Agents that register as SMART apps and launch from the EHR menu with the right scopes and audit trail.

The orchestration gap matters here. Healthcare organizations rarely have the in-house engineering team to wire SMART on FHIR against Redox, Particle Health, Health Gorilla, MedPlum, Aptible, Verifiable, Vanta, and the EHR-specific OAuth endpoints. Life Value sits in that orchestration layer, with HIPAA, GDPR, ISO/IEC 27001:2022, SOC 2 Type II, and HITRUST controls applied across the build. For patient-mediated exchange where the architecturally honest pattern is a patient-held record, we publish HealthWallet.me as the open-source FHIR-native patient EHR, encrypted on device with biometric authentication and TEFCA-certified via the FastenHealth on-prem partnership.

Further reading