SMART on FHIR Apps
Clinician EHR-launch, patient standalone, and backend apps — OAuth 2.0, launch context, US Core, validated against Inferno g10.
SMART v2OAuth 2.0US Core
EHR & EMR Integration
Integrate Your Product With Every Major EHR.
SMART on FHIR apps, FHIR R4 / US Core APIs, and HL7 v2 interfaces for Epic, Oracle Health (Cerner), athenahealth, MEDITECH and more — plus the developer program, security review, and go-live path for each. Built on patterns that pass Inferno g10.
Epic on FHIROracle HealthathenahealthSMART on FHIRFHIR R4US Core-conformant · HIPAA · BAA available
6+
EHRs integrated — Epic, Oracle Health, athena, MEDITECH, Veradigm, NextGen
3
SMART launch models we ship: EHR, standalone & backend
47/47
Inferno g10 conformance tests passing on our SMART server
R4
FHIR R4 / US Core-conformant, terminology-coded data
The EHR Integration Reality
Every EHR Is a Different Door.
They all speak FHIR now — but that's where the sameness ends. Each vendor gates production behind its own developer program, app marketplace, security review, and a per-customer authorization from every health system that runs it. "We support FHIR" and "your app is live in Epic" are months apart.
We've walked those paths. We build the integration and navigate each vendor's program so integration stops being the thing that stalls your enterprise deals.
Same standard, different programs.
Epic Vendor Services, Oracle code Console, athenahealth's Platform Services contract — each has its own gate.
Per-customer authorization, every time.
Going live in one health system doesn't unlock the next — each org signs its own consent (and athena needs a VPN).
The review is the real work.
OAuth scopes, data handling, and a security review stand between your sandbox app and a production Client ID.
Interactive · EHR Integration Explorer
Pick Your Target EHR. See the Real Path.
Every vendor's actual 2026 program, APIs, sandbox, and the gotcha that trips teams up — the map we use to get you live. Select an EHR.
Epic
Epic on FHIR (free developer program + sandbox) → Vendor Services for paid production distribution · discovery via the Showroom marketplace (the App Orchard successor, live since Jan 2024) · Connection Hub product listing.
Integration Methods
FHIR R4 (4.0.1) + US Core / USCDI v3, plus legacy STU3/DSTU2. 450+ FHIR APIs. Three SMART launch models: clinician EHR launch, patient standalone (MyChart), and backend system-to-system (SMART Backend Services, asymmetric JWT). Also CDS Hooks, FHIR Bulk Data $export, and HL7 v2 interfaces.
Sandbox & Registration
Self-service on fhir.epic.com: test against example data, then register your app to receive Production and Non-Production Client IDs. Free USCDI v3 access via open.epic (750+ no-cost APIs).
The Gotcha
App records are immutable. Once you mark an app "ready for production," you can't edit it — any change means registering an entirely new app record (and re-coordinating with the customer, who must sign the open.epic API Subscription Agreement). Epic also doesn't yet support Bulk _since incremental export.
Production & Distribution
"Free" covers the developer resources and sandbox — not production distribution, which runs through Vendor Services (paid) with a Connection Hub listing. Each customer org activates your app on their end.
What we do
Build the SMART app to US Core, validate against Inferno g10, structure the app record to survive Epic's immutability, and run the fhir.epic.com → Vendor Services → Showroom onboarding with your first customer.
Oracle Health (Cerner)
Integrations center on the Millennium Platform and Ignite APIs. Register and test apps in the code Console — which requires a free CernerCare account.
Integration Methods
FHIR R4 (4.0.1) only — DSTU2 was retired in December 2025, so any older app must be rebuilt on R4. SMART on FHIR app launch with OAuth 2.0 scopes. Supports Bulk _since incremental export.
Sandbox & Registration
Register your app in code Console to test authentication and every declared scope. A free CernerCare account is created on first use.
The Gotcha
R4-only since Dec 2025. Teams carrying legacy DSTU2 Cerner integrations must migrate. Scope declarations in code Console must match exactly what production will grant.
Naming Note
Post-Oracle acquisition, "Cerner" branding is fading into Oracle Health; "CernerCare" and "code Console" may rebrand — the platform (Millennium) and R4 requirement are the stable anchors.
What we do
Build or migrate to R4, register and scope-test in code Console, and stand up SMART launch against Millennium — including rebuilding legacy DSTU2 Cerner apps onto R4.
athenahealth
Everything routes through the athenahealth Developer Portal (register → create app → OAuth 2.0 client_id/secret) and lists in the Marketplace. Apps fall into three OAuth categories by authorization model.
Integration Methods
FHIR R4 + proprietary APIs, across three app types: 2-legged OAuth (backend/service-to-service), 3-legged PHR (patient-consented, read-only Certified APIs), and 3-legged for all other apps (patient- or provider-consented).
Sandbox & Registration
Sandbox / Preview credentials are self-service. Certified-API-only apps can request Production credentials by email; any non-Certified API requires a signed athenahealth Platform Services contract.
The Gotchas
Per-customer consent, every time: connecting to any athenaOne customer's Preview or Production environment requires that org's signed authorization-and-consent form — not a one-time gate. And environment access typically needs a site-to-site VPN + IP allow-listing, so plan network access early.
Certified vs Contract
The self-service "Certified API" lane is fast but limited; anything richer pulls you into a commercial Platform Services agreement. Knowing which lane you need up front saves weeks.
What we do
Map your use case to the right OAuth category and Certified-vs-contract lane, set up the VPN/allow-listing, and run the per-customer authorization for each athenaOne org you onboard.
MEDITECH
The developer sandbox is the Greenfield Workspace — test your integration against a real MEDITECH Expanse EHR with interactive API docs. Traverse is MEDITECH's broader interoperability platform.
Integration Methods
Live FHIR R4 / US Core APIs plus Scheduling APIs, over OAuth 2.0 / OpenID Connect. Supports both patient- and provider-facing workflows (not view-only).
Sandbox
Greenfield Workspace lets you execute APIs against a real Expanse instance loaded with test/sample data (no live PHI), with interactive documentation to develop against.
The Gotcha
Greenfield is powerful but Expanse-specific; you're validating against MEDITECH's model, and production connectivity still runs per-customer through the hospital's environment.
Good to Know
Scheduling APIs alongside US Core make MEDITECH a strong fit for access/booking and patient-engagement use cases, not just record retrieval.
What we do
Build and test in the Greenfield Workspace against Expanse, wire OAuth 2.0 / OIDC, and take you from sandbox to a live hospital connection.
Veradigm (Allscripts)
The program is Veradigm Connect (the rebrand of the Allscripts Developer Program); the marketplace is App Expo. Membership splits into Open and Integrator tiers.
Integration Methods
FHIR R4 APIs, SMART on FHIR 2.0.0 (standalone + EHR launch, plus Backend Services JWT auth), FHIR Bulk Data $export, and proprietary APIs — including the bidirectional Unity API for writes.
Tiers
Open — for anyone using select FHIR-enabled APIs. Integrator — for companies needing full access to proprietary APIs (e.g. Unity), with Bronze → Platinum-Plus subscription plans.
The Gotcha
Writes live in the Integrator tier. Read-only FHIR is available in Open, but bidirectional workflows require Integrator membership and the Unity API — a different commercial and technical footprint.
Naming Note
Lineage: Allscripts Application Store → App Expo → Veradigm App Expo after the 2023 corporate rebrand. Old "Allscripts" docs still circulate — verify against developer.veradigm.com.
What we do
Pick the right tier for your use case, build SMART 2.0 apps, and implement Unity for bidirectional read/write when Open-tier FHIR isn't enough.
NextGen Healthcare
Three separate programs by audience: Patient Access APIs, the Open Access Developer Program, and the API Distributor Program. Picking the right one is the first decision.
Integration Methods
FHIR R4 APIs and SMART on FHIR app launch, aligned to US Core for patient- and provider-facing use cases.
The Three Programs
Patient Access & Open Access — free to develop and deploy. API Distributor — free to develop (incl. sandbox), but may carry fees based on data scope and requirements.
The Gotcha
Open Access is for existing NextGen clients (Enterprise EHR v5.9.0+) building internal apps. Third-party vendors distributing to others belong in the API Distributor Program — pick wrong and you re-onboard.
Cost Note
"Free to develop" is real, but API Distributor production may carry fees — scope your data needs early so the commercial terms don't surprise you.
What we do
Route you into the correct NextGen program, build the FHIR/SMART integration, and handle Distributor onboarding for third-party distribution.
Program details verified July 2026 against primary vendor developer docs. Also integrate: eClinicalWorks, Greenway, Praxis & others. Vendor program names change — we track them.
Integration Methods
Which Mechanism, and When
EHR integration isn't one technique. We pick the right one — or combine them — for your use case.
Method
What it is
Use it when
SMART · EHR launchclinician-facing
Your app launches inside the chart in the clinician's session, with patient/user context passed in via OAuth 2.0.
You need to live inside the provider workflow — decision support, documentation, ordering.
SMART · standalonepatient-facing
The user launches your app from outside the EHR and authorizes against the patient portal (e.g. MyChart).
Patient apps: records access, PHR, engagement, patient-mediated data.
SMART · backendsystem-to-system
No user present — server-to-server auth with an asymmetric JWT (SMART Backend Services).
Automated data pipelines, analytics, population workflows.
FHIR Bulk Data$export
Export large populations of FHIR resources asynchronously (ndjson), sometimes filtered by
_since.Population health, cohorts, warehousing — where per-patient calls don't scale.
CDS Hooksreal-time
The EHR calls your service at workflow moments (e.g. order entry) and shows cards back to the clinician.
In-workflow guidance, alerts, and suggestions at the point of care.
HL7 v2 interfaceslegacy · real-time
The battle-tested messaging layer (ADT, ORU, ORM, SIU) still running in most hospitals.
Real-time events and sites where FHIR coverage is partial — often alongside FHIR.
The Onboarding Journey
From Sandbox to a Live Customer
The technical build is half the job. The other half is each vendor's program and every customer's authorization. Here's the path we run.
1
Sandbox
Register on the vendor portal; build & test against example data (fhir.epic.com, code Console, Greenfield…).
2
Register App
Get Non-Production & Production Client IDs; declare exact OAuth scopes.
3
Build & Conform
US Core-conformant reads/writes, validated against Inferno g10.
4
Security Review
Scopes, data handling, and (for many) a questionnaire + pen test.
5
Per-Customer Auth
Each health system signs off — consent forms, agreements, VPN/allow-listing.
6
Go-Live & List
Production credentials, marketplace listing (Showroom / App Expo / Marketplace), monitoring.
What We Build
EHR Integration, End to End
From a single SMART app to a multi-EHR strategy — engineered and shepherded through each vendor's program.
FHIR R4 API Integration
Read and write the record across vendors — Patient, Observation, MedicationRequest, DocumentReference and the rest of US Core.
FHIR R4Bulk $exportCDS Hooks
HL7 v2 Interfaces
ADT, ORU, ORM, SIU feeds via Mirth Connect / interface engines — for real-time events and sites where FHIR coverage is partial.
HL7 v2MirthADT/ORU
Multi-EHR Abstraction
One integration layer across Epic, Oracle Health, athena and more — so your product isn't rewritten per vendor.
NormalizationUS Core1 API
Marketplace Onboarding
Registration, Client IDs, and listings on Epic Showroom / Vendor Services, athenahealth Marketplace, Veradigm App Expo.
ShowroomApp ExpoListing
Security Review Support
OAuth scope hygiene, data-handling docs, questionnaires, pen-test prep, BAA — so you pass the review, not stall on it.
HIPAABAAPen test
Standards & The 2026 Rules That Opened the EHRs
Why Every EHR Now Has an API
EHR openness isn't goodwill — it's regulation. These are the standards we build to and the mandates driving the roadmap.
FHIR R4 · US Core
The Data Baseline
FHIR R4 (4.0.1) with US Core profiles over the USCDI data set — the common shape every certified EHR API must expose.
SMART App Launch v2
Launch & Auth
Two launch flows (EHR + standalone) and granular v2 scopes — c/r/u/d/s per resource (e.g. patient/Observation.rs) replacing v1's coarse read/write.
ONC (g)(10) · Inferno
Certified API
The ONC/ASTP Standardized API certification requires FHIR R4 + US Core + SMART + Bulk Data, tested with the Inferno kit. It's why the APIs exist — and the bar we build to.
CMS-0057-F
Prior-Auth & Access APIs
The CMS Interoperability & Prior Authorization rule requires impacted payers to run FHIR Patient Access, Provider Access, Payer-to-Payer & Prior-Auth APIs.▲ Most requirements effective Jan 1, 2027
HTI-1 / USCDI
Certification Updates
ONC's HTI rules advance the certified-API requirements and the USCDI data set (v3 today, v4 published) — expanding what apps can rely on being there.
TEFCA · Bulk Data
Network-Scale Exchange
TEFCA/QHINs and FHIR Bulk Data $export push exchange from per-patient calls toward population-scale — where roadmaps are heading.
Regulatory summary for orientation; dates and scope evolve — we confirm current requirements per engagement.
Proof, Not Promises
EHR Integration We've Shipped
Production integration engineering at health systems and digital-health companies.
SMART on FHIR
Inferno G10-Passing SMART Server
Built a standalone SMART on FHIR server (RS256) that passes 47/47 ONC g10 conformance tests — the same bar an app must meet to launch inside a certified EHR.
47/47
g10 tests
US Core
conformant
Legacy migration
HL7 v2 → FHIR R4 Migration
Migrated 52 healthcare interfaces from HL7 v2 to FHIR R4 with zero downtime — the exact modernization Oracle Health's DSTU2→R4 retirement now forces on Cerner apps.
52
interfaces
0
downtime
Cross-vendor sync
Cross-Hospital Clinical Data Sync
Synchronized clinical data across independent facilities in real time via a FHIR canonical layer — without disrupting each site's incumbent EHR.
Real-time
cross-site
FHIR
canonical
Engagement Models
Work with Us the Way That Fits
A fixed scope with a fixed price, or a dedicated EHR-integration team as an extension of yours.
Model 01
Fixed-Price Integration
Best when the target EHR and use case are clear. Share the requirement, get a discovery call, and receive a fixed estimate and timeline — milestone-billed.
- Fixed price, fixed timeline
- One EHR, one use case, to go-live
- Marketplace onboarding included
Model 02
Dedicated EHR Team
Best for a multi-EHR roadmap. Dedicated FHIR / SMART / HL7 engineers with 160 focused hours each per month — an extension of your team.
- 160 focused hours / engineer / month
- Multi-EHR: Epic + Oracle + athena…
- Complimentary Delivery Manager
FAQ
EHR Integration, Answered
The questions every team asks before they start.
How Long Does It Take to Integrate with an EHR Like Epic?
It depends on scope and — critically — the vendor's program and your first customer, not just the code. A read-only, US Core FHIR integration is typically the fastest; bidirectional read/write and HL7 v2 workflows take longer, and each health-system go-live adds its own authorization and (often) security review. We scope your specific EHR + use case on a discovery call and give you a realistic timeline before you commit.
Is Epic Integration Free? What About "App Orchard"?
Epic on FHIR — the developer program, sandbox, and documentation on
fhir.epic.com — is free, and open.epic exposes 750+ no-cost APIs. But "free" covers development, not production distribution: that runs through Vendor Services (paid) with a Connection Hub listing, and apps are discovered on the Showroom marketplace. "App Orchard" is the old name — it was retired and split into Vendor Services + Showroom.Which EHRs Do You Integrate With?
Epic, Oracle Health (Cerner), athenahealth, MEDITECH, Veradigm (Allscripts), and NextGen — plus eClinicalWorks, Greenway and others. Because they all expose FHIR R4 / US Core, a single well-built integration layer can span several; the differences are each vendor's developer program, proprietary APIs, and per-customer onboarding, which we handle.
What's the Difference Between a Provider App and a Patient App?
A provider (clinician-facing) app uses SMART EHR launch — it opens inside the chart in the clinician's session with patient/user context. A patient app uses SMART standalone launch — the patient authorizes it against the portal (e.g. Epic MyChart). There's also a backend model (no user) for system-to-system data. Each has different scopes, review, and consent — we build to whichever your product needs.
Do We Have to Re-Do Work for Every Hospital That Uses Our App?
The build is reusable, but access is per-customer. Each health system authorizes your app in their environment — for example, athenahealth requires each athenaOne org's signed consent form (and typically a site-to-site VPN). We standardize that onboarding so adding customer #10 is fast, not another project.
Why Does Epic Make You Register a Whole New App to Change One?
Once an Epic app record is marked "ready for production," it's immutable — any change requires registering a new app record and re-coordinating with customers. It's a real operational gotcha, so we design your scopes, redirect URIs, and app structure up front to minimize re-registrations down the line.
Let's Get You Into the EHR
Tell Us Which EHR You're Targeting.
Book a scoping call — we'll map your target EHR, the right integration method, the program and review gates, and a realistic path to a live customer. Reviewed by an integration engineer, not a sales queue.
+1 (669) 649-0706
hello@nirmitee.io
USA
Iselin, NJ 08830
India
Baner, Pune, MH 411045
Thanks — We've Got It.
A Nirmitee integration engineer will reach out within one business day.