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
Multi-EHR Integration Architecture
Different EHRs. A deliberate integration strategy.
Before you commit to a delivery date, understand the access path. Compare vendor APIs, authorization models and customer dependencies, then decide what your product should standardize—and what stays vendor-specific.
For healthcare product leaders, engineering teams and health IT teams.
- 01
Define the clinical workflow
Who uses it? Which data? Read, write or both?
- 02
Check the access path
Vendor capabilities · customer approval · authorization
- 03
Choose the integration boundary
Shared product model + vendor-specific adapters
An architecture plan that separates reusable work from site-specific work.
Illustrative delivery path · no patient dataClear scope.
Tangible deliverables.
01Vendor capability comparison
02Authorization and access plan
03Build-versus-platform decision
How is this architecture guide different from your EHR integration service?
This guide helps engineering teams compare platforms and plan their architecture. Our EHR and EMR integration service covers implementation: adapters, data mapping, customer-environment testing, rollout and agreed operational handover.
Technical reference: HL7 FHIR implementation concepts ↗The EHR Integration Reality
Every EHR Is a Different Door.
An EHR’s API catalogue is only the starting point. Product version, enabled endpoints, customer permissions and review requirements can change the integration scope. Confirm each dependency before setting a delivery date.
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.
A connection in one health system does not establish access in another. Confirm each customer’s approvals and network requirements.
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
Plan clinical app launch, backend data access or an interface workflow against the customer’s Epic environment.
Integration Methods
Map the requested resources and read/write operations to the target Epic endpoint. Validate the SMART launch or backend authorization path required by the workflow.
Sandbox & Registration
Use the relevant Epic developer documentation and test environment. Record the client IDs, redirect URIs and scopes for each environment.
The Gotcha
Check app-change procedures and supported search or export parameters before designing a release. Do not assume sandbox capabilities match the customer environment.
Production & Distribution
Confirm customer activation and any applicable agreements, listing requirements and fees directly with Epic and the health system.
What we do
Translate these findings into the access plan, data mapping, integration tests and customer rollout checklist.
Oracle Health (Cerner)
Assess the Oracle Health platform, API version and customer environment before defining implementation scope.
Integration Methods
Inventory the customer’s Oracle Health platform and available API versions before selecting a migration or new-build approach.
Sandbox & Registration
Register and test through the applicable Oracle Health developer environment. Exercise the actual resource operations and authorization scopes required.
The Gotcha
For a legacy integration, check the current support and retirement notices. Migration scope depends on the endpoints and behaviours the application uses.
Naming Note
Distinguish the customer’s product and platform from historical Cerner branding when locating documentation and requesting access.
What we do
Translate these findings into the access plan, data mapping, integration tests and customer rollout checklist.
athenahealth
Map the workflow to the appropriate athenahealth API family and customer authorization.
Integration Methods
Choose between the available FHIR and vendor-specific API paths by workflow, resource coverage and authorization model.
Sandbox & Registration
Confirm the registration, credential and commercial requirements for the particular API family. Sandbox access is not production approval.
The Gotchas
Record the customer authorization and network requirements. Do not assume a VPN is required for every athenahealth API integration.
Certified vs Contract
Separate the data you need from the API programme that grants it, and confirm contractual scope before development.
What we do
Translate these findings into the access plan, data mapping, integration tests and customer rollout checklist.
MEDITECH
Start with the hospital’s MEDITECH product and supported integration capabilities.
Integration Methods
Check the customer’s MEDITECH product and version, required data and available read or write operations.
Sandbox
Use the applicable MEDITECH developer environment to test with sample data, then validate against the customer’s target environment.
The Gotcha
A successful sandbox test does not establish that a hospital has enabled the same endpoints or permissions.
Good to Know
For scheduling and patient-engagement workflows, confirm the specific operations and access model rather than assuming a clinical-data API includes them.
What we do
Translate these findings into the access plan, data mapping, integration tests and customer rollout checklist.
Veradigm (Allscripts)
Separate the Veradigm product, available API operations and distribution requirements.
Integration Methods
Evaluate the applicable Veradigm APIs against the required clinical workflow. Treat read access and write-back as separate scope decisions.
Tiers
Confirm developer registration, environment access and any partner programme requirements for the chosen product.
The Gotcha
Validate that the required operations are supported and authorized. Do not assume an available FHIR read endpoint permits updates.
Naming Note
Identify the specific customer product when following older Allscripts references; historical brand names alone are not an API specification.
What we do
Translate these findings into the access plan, data mapping, integration tests and customer rollout checklist.
NextGen Healthcare
Match the NextGen product and integration programme to your intended customer workflow.
Integration Methods
Identify the specific NextGen product, API family and authorization model that can support your workflow.
The Three Programs
Confirm the programme appropriate to internal customer use or third-party distribution, and obtain current access requirements.
The Gotcha
Check customer version, permissions and deployment requirements before promising availability of an operation.
Cost Note
Request the current commercial terms for your distribution and data scope; do not infer production pricing from developer access.
What we do
Translate these findings into the access plan, data mapping, integration tests and customer rollout checklist.
Planning checklist, not a guarantee of vendor compatibility. Confirm current documentation and customer-specific access before implementation. Epic documentation · Oracle Health documentation · athenahealth documentation
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, network access as applicable.
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 — to support the customer’s review and identify gaps early.
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 — with the applicable profile version and resource coverage confirmed for the endpoint.
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
Certification requirements evolve. Record the applicable criteria, profile versions and customer capabilities; a published data standard does not guarantee every field is populated.
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.
Delivery acceptance
Turn the comparison into an implementation brief.
Agree on these outputs during scoping. Your team should know what it will receive and how to review it.
Capability matrix
Required clinical data and operations mapped to each vendor’s supported access path.
Dependency register
Customer approvals, commercial onboarding, sandbox limits and environment setup made explicit.
Architecture decision
A documented rationale for direct adapters, an integration platform or a hybrid approach.
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"?
Developer resources, production access and distribution arrangements are separate considerations. Confirm current Epic programme terms, the APIs your workflow needs and the customer’s activation requirements before estimating total cost.
Which EHRs Do You Integrate With?
We assess integration requirements for platforms such as Epic, Oracle Health, athenahealth, MEDITECH, Veradigm and NextGen. Feasibility depends on the customer’s product version, supported operations and access permissions; a shared model does not remove those differences.
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?
Adapters and test patterns can be reusable, but each customer needs its own access, configuration and workflow validation. We document reusable components and site-specific onboarding work separately.
How should we plan changes to an Epic app?
App configuration changes can affect client IDs, redirect URIs, scopes and customer activation. Check the current Epic app-management procedure for the change in question, then plan testing and customer communication before release.
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.