Epic and Oracle Health SMART app
DemonstratedOne app run against both developer sandboxes in a single session.
Where it stops: Sandboxes only, with no hospital configuration.
Watch the run ↗EHR integration company for healthcare software teams
EHR and EMR Integration Services
We are the EHR integration company healthcare software teams bring in when a customer asks "do you integrate with our EHR?" We build and run the connection to Epic, Oracle Health, athenahealth, eClinicalWorks, NextGen, MEDITECH, Veradigm and Practice Fusion over FHIR R4, HL7 v2, X12 and C-CDA, and we sign BAAs.
For digital health companies, healthcare SaaS vendors, payers and provider groups that need EHR data inside their own product.
- 8 EHR platforms
- Epic, Oracle Health, athenahealth, eClinicalWorks, NextGen, MEDITECH, Veradigm, Practice Fusion
- 5 integration methods
- FHIR R4 APIs, HL7 v2 feeds, X12 EDI, C-CDA documents, bulk FHIR export
- One owner
- Build, customer go-live and monitoring by the same engineering team
Evidence you can check
- Founded in 2020
- Rated 4.7 on Clutch (12 reviews, November 2026)
- ISO 27001:2022 certified
- HIPAA safeguards built in; we sign BAAs
- Our team has built 350+ interfaces on Mirth Connect
- SMART on FHIR app run against the Epic and Oracle Health developer sandboxes in one session
Evidence, by status
What we can show across EHRs, by vendor
No firm has the same depth on every EHR. Ask each vendor for this table, for the EHR your next customer runs.
athenahealth patient access
DemonstratedOur recorded walkthrough in athenahealth's test environment.
Where it stops: Patient access only, with no provider launch or production write-back.
Watch the walkthrough ↗eClinicalWorks healow SMART
DemonstratedOur recorded healow walkthrough.
Where it stops: The flow shown only. Scheduling and write-back need their own agreements.
Watch the walkthrough ↗MEDITECH Expanse
ProposedA plan from MEDITECH's published Greenfield and API documents.
Where it stops: We have no public MEDITECH recording to show yet.
One normalized layer over several EHRs
ProposedOur open-source SDK keeps vendor differences in configuration.
Where it stops: Your product's data model decides how much can really be shared.
See the SDK ↗Production at your customer's site
Access-dependentNeeds that customer's approval, configuration and sign-off, on any EHR.
Where it stops: Ask us what can be shared under NDA for your vendor.
The short answer
What EHR Integration Services Include
EHR integration services connect your application to the electronic health record your customer already runs, so patient demographics, encounters, orders, results, notes and claims move without re-typing. A complete engagement covers five things: choosing the access route for each EHR (vendor FHIR API, HL7 v2 interface, X12 transaction or an aggregator), getting registered in the vendor's developer program, mapping the data to your product model with standard codes (LOINC, SNOMED CT, RxNorm, ICD-10-CM, CPT), testing in the vendor sandbox and the customer's test environment, and running the interface in production with alerting and reprocessing. EMR integration is the same work; EMR is the older term for a single practice's chart, EHR the broader record.
Still deciding how one product should serve many EHRs? Read our multi-EHR integration guide first, then come back here to scope the build.
New to the topic? Start with our plain guide to EHR integration and what it unlocks for interoperability.
Vendor by vendor
EHR and EMR Platforms We Integrate with
Every EHR exposes data differently. The API that works for one vendor is often read-only, partner-gated or absent on the next. This is how the main US platforms open up in 2026 and what usually sets the pace.
| EHR | API route | HL7 v2 and other feeds | Access program | What sets the pace |
|---|---|---|---|---|
| Epic | FHIR R4 (US Core, SMART App Launch 2.0, Bulk Data) listed on open.epic; Epic proprietary APIs for some write workflows | HL7 v2 ADT, ORM, ORU, SIU and MDM through each customer's Bridges interface team | open.epic registration, Epic Showroom listing when the product needs it, and each health system's approval of your client ID | The customer's Epic analyst queue and security review |
| Oracle Health (Cerner) | Millennium FHIR R4 APIs registered in the Oracle Health code console, with SMART launch | HL7 v2 through the customer's interface team and integration engine | Oracle Health developer program, then per-tenant enablement by the customer | Tenant activation and which FHIR write operations the site enables |
| athenahealth | athenaOne REST APIs plus certified FHIR R4 endpoints | HL7 v2 for selected lab, ADT and document flows | athenahealth Marketplace partner program and practice-level API enablement | Marketplace onboarding and the API subscription tier your workflow needs |
| eClinicalWorks | Certified FHIR R4 APIs for read and bulk export; partner APIs for write workflows | HL7 v2 interfaces configured by the eCW interface team | eCW partner agreements and practice-level interface approval | Interface scheduling on the practice's eCW instance |
| NextGen Healthcare | NextGen Enterprise and Office FHIR R4 APIs plus the NextGen Enterprise API | HL7 v2, often routed through Mirth Connect at the practice | NextGen partner program and per-practice activation | Which API product the practice licenses |
| MEDITECH | Expanse FHIR R4 (US Core) APIs, developed and tested in Greenfield Workspace | HL7 v2 is still the main route for Expanse, Client/Server and MAGIC hospitals | MEDITECH Greenfield Workspace and the hospital's interface team | Hospital interface team capacity and the MEDITECH platform generation |
| Veradigm (Allscripts) | Unity API and FHIR R4 for TouchWorks and Veradigm EHR | HL7 v2 for results, ADT and scheduling | Veradigm Developer Program and practice licensing | Unity API licensing for the specific practice |
| Practice Fusion | Certified FHIR R4 API, strongest for read access | C-CDA exports and limited interface options | Practice Fusion developer access and practice authorization | Write-back scope, which is narrower than on enterprise EHRs |
Vendor service pages: Epic integration · Oracle Health integration · athenahealth integration · eClinicalWorks integration · MEDITECH integration · Practice Fusion integration · PointClickCare integration · Dentrix integration · Dental practice management integration
How the data moves
EHR Integration Methods: FHIR, HL7 V2, X12, C-CDA and Bulk
Most real projects use two or three of these at once. A scheduling product might read FHIR Appointment and Slot, receive HL7 v2 SIU messages for changes, and send X12 270 eligibility checks.
| Method | What it carries | Best for | Watch for |
|---|---|---|---|
| FHIR R4 REST APIs | US Core resources such as Patient, Encounter, Observation, Condition, MedicationRequest, DocumentReference | Apps that read or write on demand, SMART on FHIR launch inside the EHR | Write support varies by vendor and site; rate limits and scopes |
| HL7 v2 messages | ADT A01/A04/A08, ORM^O01, ORU^R01, SIU^S12, MDM^T02, DFT^P03 | Real-time hospital events, lab and radiology results, charges | Site-specific Z-segments and field use; interface engine needed |
| X12 5010 EDI | 270/271 eligibility, 276/277 claim status, 278 prior auth, 837P/I claims, 835 remittance | Revenue cycle and payer workflows next to the EHR | Clearinghouse enrollment lead times and payer companion guides |
| C-CDA R2.1 documents | CCD, Discharge Summary, Referral Note over Direct, XDS or Carequality and CommonWell | Transitions of care and record exchange with other organizations | Parsing narrative sections and de-duplicating repeated documents |
| Bulk FHIR ($export) | NDJSON files of whole patient groups under SMART Backend Services | Analytics, population health, payer data, migration | Export windows, group definitions and incremental loads |
| Integration platforms | Normalized APIs over many EHRs from vendors such as Redox, Health Gorilla or Particle Health | Reaching many sites fast when per-transaction cost is acceptable | Per-connection fees, data coverage per EHR and exit plan |
The HL7 v2 vs FHIR choice is rarely either-or. Certified EHRs must expose FHIR R4 under the ONC (g)(10) criterion, while most hospital event feeds still run on HL7 v2.
Your starting point
When Teams Hire an EHR Integration Company
A Signed Customer Is Waiting on the EHR Connection
Sales closed a health system or group practice and go-live depends on reading its EHR data or writing back into it. We confirm the exact EHR, version and enabled interfaces, then build to that customer's environment.
What you receiveAccess plan, data map and a dated go-live path for that customer
Your Roadmap Spans Several EHRs
The next five customers run three different EHRs. We build one internal data model with an adapter per vendor, so the second Epic site is configuration, not a rebuild.
What you receiveShared canonical model, per-vendor adapters and a reusable test pack
An Existing EMR Integration Keeps Failing
Messages drop, patients mismatch or nobody knows why a result never arrived. We inventory the interfaces, add monitoring and reprocessing, and fix the root causes before extending anything.
What you receiveInterface inventory, failure analysis and a stabilization plan
Buyer decision
Build EHR Integrations In-house, Use a Platform, or Hire an EHR Integration Company
The right answer depends on how many EHRs you must reach, how deep the workflow goes and who will run the interfaces after launch.
| Option | Works well when | Where it strains | Who runs it after go-live |
|---|---|---|---|
| In-house team | One EHR, deep product-specific workflow, and engineers who already know FHIR and HL7 v2 | Hiring integration specialists; vendor programs and customer IT teams slow the first launch | Your team |
| Integration platform or aggregator | Many sites, read-heavy use cases, speed matters more than unit cost | Per-connection fees at scale, gaps in write-back and vendor-specific data | The platform, with your team on escalations |
| EHR integration company (Nirmitee) | You need a production connection now and want to own the custom code and mappings once paid | Needs a clear internal product owner for workflow decisions | Us under a support agreement, or your team after handover |
| Hybrid | Platform for breadth, direct FHIR or HL7 v2 for your deepest workflows | Two integration patterns to monitor | Shared, with one runbook |
Who owns what
Integration Boundaries We Agree Up Front
We build
Adapters, FHIR clients and SMART launch, HL7 v2 channels, X12 transaction handling, data mapping, identity matching, error queues, dashboards and runbooks.
Your customer provides
EHR access, interface team time, the approval of your client ID or interface request, test patients and clinical sign-off on workflows.
The EHR vendor controls
Developer program terms, which APIs and write operations exist, marketplace listing reviews and any vendor fees.
Your product owns
Clinical workflow decisions, what users see, and consent and data-use terms with your customers.
What you keep
EHR Integration Deliverables
Integration specification
Workflow, source and target systems, message and resource list, trigger events and error handling, reviewed by your team and the customer.
Data mapping workbook
Field-level mapping with code systems (LOINC, SNOMED CT, RxNorm, ICD-10-CM, CPT), transforms and test cases.
Working connectors
FHIR clients, SMART on FHIR launch, HL7 v2 channels or X12 handlers in your repository or on Interoply, our integration platform.
Test evidence
Sandbox and customer test-environment results, including negative cases, duplicates and corrections.
Go-live runbook
Cutover steps, rollback criteria, monitoring thresholds, alert routing and reprocessing procedures.
Handover or managed support
Documentation and knowledge transfer, or ongoing monitoring under a support agreement.
Delivery phases
How We Deliver EHR Integration, Step by Step
Engineering is rarely the slowest part. Customer access, vendor programs and interface team queues usually set the date, so we plan those first.
Discovery and access plan
1 to 2 weeks
Build against the sandbox
3 to 6 weeks for a read-focused FHIR or HL7 v2 flow
Customer test environment
2 to 6 weeks, set mostly by the customer's IT team
Go-live and hypercare
1 to 2 weeks, then steady-state monitoring
Write-back into the chart, a first Epic Showroom listing or a new clearinghouse enrollment typically adds weeks to months on the vendor side.
Budgeting
What Drives EHR Integration Cost
We quote after discovery because these factors change the effort more than the choice of vendor does.
Number of EHRs and customer sites
Each new vendor needs an adapter; each new site needs configuration, testing and go-live support.
Read only or write-back
Writing orders, notes or results into the chart needs more validation, clinical sign-off and often partner-level API access.
Method mix
FHIR alone is lighter than FHIR plus HL7 v2 plus X12. Each method adds its own testing and monitoring.
Data volume and history
Real-time feeds, bulk backfills and historical migration change the storage, throughput and reconciliation work.
Vendor program and customer IT
Marketplace fees, security questionnaires and interface team availability sit outside our code but shape the plan.
Run and support model
A handover to your team costs less upfront; a managed service with monitoring and on-call support costs less to operate.
Delivered work
EHR Integration Work We Have Delivered
Client names are withheld; each is a real engagement. Our open-source work is public on GitHub.
SMART on FHIR App Across Epic and Oracle Health
One SMART on FHIR application launched and read patient data from the Epic and Oracle Health developer sandboxes in the same session, with vendor-specific scope handling.
EngagementMulti-EHR · SMART App Launch · FHIR R4
Behavioral Health Claims Integration Hardening
Hardened an inherited clearinghouse integration for a behavioral health EHR: claim validation, 999 and 277CA acknowledgement handling and 835 remittance reconciliation.
EngagementX12 5010 · United States
Read the engineering case study →Cross-hospital Cancer Case Exchange
A referral and tumour-board exchange across a regional hospital network, where every record stays at its source hospital and only the agreed case data moves.
EngagementHospital network · Sandbox and integration testing
Read the engineering case study →Offline Screening EMR with Device Capture
A clinic record that captures readings from connected devices offline and reconciles with the central record when the network returns.
EngagementEMR and device integration · Live in production
Open-source Headless EHR on FHIR R4
Our headless EHR passed all 47 tests in the ONC (g)(10) SMART App Launch Standalone Patient App suite in Inferno on October 27, 2026, so we test integrations against the same criteria certified EHRs meet.
EngagementOpen source · Public repository
View the repository on GitHub →Mirth Connect Interfaces at Scale
Our team has built more than 350 interfaces on Mirth Connect, covering ADT, orders, results, documents and charges between EHRs, labs and products.
EngagementHL7 v2 · Interface engine
See our Mirth Connect services →Tell us which EHR your next customer runs. We will map the fastest route to production on the first call.Book a call
What Are EHR Integration Services?
EHR integration services connect a healthcare application to an electronic health record so data moves automatically in one or both directions. The work covers choosing the access route (FHIR API, HL7 v2 interface, X12 transaction or an aggregator), vendor program registration, data mapping, testing in sandbox and customer environments, go-live and ongoing monitoring.
What Is the Difference Between EHR Integration and EMR Integration?
The engineering is the same. EMR usually means one practice's digital chart and EHR the broader record shared across organizations, so buyers use both words for the same project. We scope by the actual product, such as Epic, athenaOne or eClinicalWorks, and the data you need.
How Much Does EHR Integration Cost?
Cost depends on the number of EHRs and customer sites, read-only versus write-back, the method mix (FHIR, HL7 v2, X12), data volume, vendor program fees and the support model after go-live. We give a fixed scope and estimate after a short discovery rather than a list price, because those factors move the effort more than the vendor name.
How Long Does an EHR Integration Take?
A read-focused FHIR or HL7 v2 integration with one EHR typically takes 6 to 12 weeks from discovery to production, most of it set by customer access and test environments. Write-back, a first marketplace listing or a new clearinghouse enrollment usually adds more time on the vendor side.
Which EHR and EMR systems do you integrate with?
Epic, Oracle Health (Cerner), athenahealth, eClinicalWorks, NextGen, MEDITECH, Veradigm (Allscripts) and Practice Fusion, plus specialty and open-source EHRs that support FHIR R4 or HL7 v2. We confirm the exact version and enabled interfaces for each customer before committing to a date.
Should We Use FHIR or HL7 V2 for EHR Integration?
Use FHIR R4 when your app reads or writes on demand or launches inside the EHR with SMART on FHIR. Use HL7 v2 when you need real-time hospital events such as admissions, orders and results. Many products need both, and we design one internal model so the method does not leak into your code.
What Is EMR API Integration?
EMR API integration means connecting to the EHR through the vendor's published APIs, usually certified FHIR R4 endpoints plus proprietary REST APIs, instead of file drops or screen scraping. It needs a registered app, OAuth 2.0 scopes through SMART App Launch, and the customer's approval to connect to their instance.
Do we need to join Epic Showroom or the athenahealth Marketplace?
Not always. Many read-only FHIR use cases only need open.epic registration and customer approval of your client ID. Marketplace programs matter when you need proprietary or write APIs, or when customers expect a listed app. We map which programs your workflow actually requires.
Should We Use an Integration Platform Like Redox or Build Direct?
Platforms reach many EHRs quickly and suit read-heavy use cases. Direct FHIR or HL7 v2 connections give more control, deeper write-back and lower unit cost at scale. Many teams run a hybrid. We build on either and can run your connections on Interoply, our integration platform.
Can you write data back into the EHR?
Yes, where the EHR and the customer allow it. Common write-backs are clinical notes as DocumentReference, results over HL7 v2 ORU, appointments, and charges over DFT. Write access usually needs partner-level API rights and clinical sign-off, so we confirm it in discovery.
How Do You Handle HIPAA and Security in EHR Integration?
We sign a Business Associate Agreement, and Nirmitee is ISO 27001:2022 certified. Integrations use least-privilege OAuth scopes, encryption in transit and at rest, audit logging of every message, and synthetic data in development. We complete customer security questionnaires as part of the plan.
What Happens After the EHR Integration Goes Live?
We hand over code, mappings and runbooks to your team, or monitor the interfaces for you with alerting, reprocessing of failed messages and updates when the EHR vendor changes an API or a customer upgrades.
Architecture
One product, several EHRs: what stays shared and what cannot
A universal EHR connection is the claim to test first. These two views show where shared code stops and site work starts.
From your product down to each customer's EHR
A proposed reference design. The adapter holds the vendor rules, and site configuration holds the customer rules.
- 1. Your productAsks in your own terms
Book a visit, read results, file a note. Your code never names a vendor.
- 2. Integration layerFinds the customer, then the vendor adapter
Epic, Oracle Health, athenaOne, eClinicalWorks or MEDITECH rules live in one adapter each.
- 3. Integration layerApplies that site's configuration
Endpoints, scopes, code mappings and which actions are on.
If it fails: An action this site has not enabled returns a plain refusal, not an empty result.
- 4. Customer's EHRTakes the call by its supported route
FHIR, a vendor API, HL7 v2 or a document, whichever the site allows.
- 5. Integration layerMaps the answer back to your model
Source values are kept beside mapped ones so a wrong mapping can be traced.
If it fails: Unmapped values go to a review list. They are not guessed.
- 6. Your productShows what happened
Success, refusal or pending, with the reason a user can act on.
Proposed design, written October 31, 2026. Vendor rules from the vendor documents listed below.
Who approves what, by vendor
The approval path differs more than the code. Read down for the same stage on each EHR.
- 1. athenaOne, eClinicalWorksPractice-level enablement
Each practice turns the app on. Writes need a separate vendor contract.
- 2. Epic, Oracle HealthHospital-level activation
Each health system configures the app and approves its workflow.
- 3. MEDITECHVendor registers for the hospital
MEDITECH registers the app on the hospital's behalf, so each go-live needs a sponsor.
If it fails: With no hospital sponsor, work can reach Greenfield, but no further.
- 4. Epic, Oracle HealthInterface team for HL7 feeds
Site analysts set the spec and the test window.
athenahealth documents read September 25, 2026; eClinicalWorks read 25 Sep and October 28, 2026; Epic and Oracle read October 31, 2026; MEDITECH read 26 Sep and October 31, 2026. Terms change, so confirm them for your contract.
Failure modes
What breaks when you add the next EHR
Your first connection teaches little about your fifth. These are the failures that come with scale.
A mapping built for one customer breaks at the next
- How it gets noticed
- A mapping check against sample data before each site starts
- What we do
- Mappings live in per-site configuration, with the source value stored.
- The limit
- A check covers the codes in the sample. Rare codes surface later, on the review list.
A shared feature is missing on one vendor
- How it gets noticed
- A capability matrix per vendor and site, checked at scoping
- What we do
- The product shows the feature as off for that site, and sales can see the matrix.
- The limit
- Some workflows have no route on a given EHR at all. We say so at scoping.
A vendor upgrade changes an adapter
- How it gets noticed
- Contract tests per adapter, on a schedule, where test systems allow
- What we do
- The failing adapter is fixed alone; other vendors keep running.
- The limit
- Coverage depends on test access. Some changes first appear in production.
One customer's outage backs up everyone
- How it gets noticed
- Queue depth per customer, on a dashboard
- What we do
- Queues and rate budgets are kept per customer.
- The limit
- Separate queues limit the spread. Shared parts, such as your own database, still need their own plan.
Decision makers
If you are choosing an EHR integration company
What to weigh, and what stays yours.
Main risks
Buying for the demo vendor when your next customer runs another EHR. Scope against your real customer list.
PHI
BAA first, and test data until then. Each workflow names its fields, storage and retention before build.
Code and lock-in
Once paid, you own the custom code, mappings, runbooks and all of your data, so you can leave. We keep our reusable tools and open-source parts. A platform can be faster to start, but check the exit terms.
Team
A technical lead who stays on the project, engineers and your own product owner. Meet the lead before signing.
What you receive
Custom source code, a capability matrix per vendor and site, mapping files, test evidence, runbooks and a handover.
Your security review
ISO 27001:2022 certified, and we sign BAAs. Ask for the certificate and scope.
Six questions for any EHR integration company
- Which of our next three customers' EHRs have you actually run, and where?
- What is shared across vendors, and what is rebuilt per site?
- Who owns the code and credentials if we part ways?
- What is your evidence: sandbox, test system or production?
- How do we see a failed message, and who gets the alert?
- What will you tell us cannot be done?
Vendor sources behind these diagrams
- Epic on FHIR, read October 31, 2026
- Oracle Health authorization framework, read October 31, 2026
- MEDITECH patient access API FAQs, read October 31, 2026
- athenahealth onboarding overview, read September 25, 2026
Start the integration
Which EHR Is Your Next Customer on?
Share the EHR, the workflow and the data you need. We reply with the access route, the dependencies on the customer side and a realistic go-live path.
Prefer to talk it through?
Contact the team directly ↗A product overview and a de-identified example are enough. No patient records or credentials.
Thank you. Your inquiry has been received. Our team will review your requirements.
Standards and Vendor References
Primary specifications and vendor developer programs behind the methods on this page.