01
Scoping review
Which EHRs, what's realistic, and what it costs — before you promise a date.
1–2 weeksFixed price
EHR & EMR Integration Services
Your Customers Are Not All on the Same EHR.
One deal wants Epic. The next runs Oracle Health. A third is on athenahealth and expects you live in a month. We build the layer that makes all of them look the same to your product — so the next EHR is a configuration, not another quarter.
EpicOracle HealthMEDITECHathenahealtheCW · NextGen · VeradigmFHIR, SMART and HL7. ISO 27001. BAA available.
Which one is your week? pick one
01“Our first customer is on Epic and wants us live.”What it takes, and what it really costs02“Every deal now asks for a different EHR.”How to stop rebuilding each time03“Do we build direct, or pay for middleware?”The honest trade-off, from someone who does both04“We have integrations, but each one is different.”How to consolidate without a rewriteEvery one of these is a call we've taken. Pick yours and we'll answer it below.
7+
EHR platforms we've connected products to
52
Connections rebuilt without interrupting care
47/47
Federal certification tests passed, first submission
1
Interface your product has to learn, however many EHRs you add
Straight answers
Four Versions of This Conversation.
We've had all of them. Pick the one that sounds like your week.
“Our first customer is on Epic and wants us live.”
One EHR, one hospital, and a date you've probably already given them.
2–4 months
typical, first customer live
What actually gates you
Not the code. Every EHR vendor runs its own developer programme, and every hospital runs its own security review on top. You go live per customer, not once. The build is usually the shortest part of the calendar.
The fastest honest route
Read-only first, one data area, one customer. It gets you a reference site and a real security review under your belt. Write-back and extra data areas are additive afterwards — and much easier to sell once something is live.
Decisions you can't undo cheaply
Some registrations lock once you mark them production-ready. Get the scopes and structure right the first time, or you re-register and re-review. The per-vendor mechanics are here →
“Every deal now asks for a different EHR.”
You won on Epic. The next three prospects are on Oracle Health, athenahealth and something you've not heard of.
N × N → N
the whole argument
Why the second one hurts
If your first integration was built directly into your product, the second is a second copy — with its own quirks, its own bugs and its own maintenance. Three EHRs done this way is where most teams stall.
What fixes it
One internal model that every EHR maps into, and per-vendor adapters that are thin and replaceable. Your product learns one interface no matter how many EHRs you support. There's a picture of this below.
When to do it
Before the third EHR. It's a normal amount of work to design in and an expensive one to retrofit once several are live and each has quiet exceptions. If you're at two and signing more, now.
“Do we build direct, or pay for middleware?”
Redox and Health Gorilla quoted you. Your engineers think they can do it themselves. Both are right, in different situations.
We do both
and don't resell either
Middleware wins when
You need several EHRs quickly, your team is small, and standard read and write is enough. You're buying time and breadth, and paying a per-transaction or subscription cost you don't control.
Direct wins when
One or a few EHRs, deep workflows, or volumes where a per-transaction fee becomes your largest line item. You own the connection and there's no ceiling on what you can reach.
Why ask us
We build native integrations and onboard teams onto middleware when that's genuinely better. We don't resell it and take nothing either way, so the recommendation is just a recommendation. The full comparison is below.
“We have integrations, but each one is different.”
Three EHRs, three approaches, three people who each understand one of them.
No rewrite
consolidation is incremental
Do we have to start again?
No, and we'd argue against it. Consolidation is done one connection at a time, behind a shared model, with the old path live until the new one is proven. Nothing goes dark.
What you get first
A written map of what's actually running across every customer — what's live, what's dead, and where the same idea has been solved three different ways. Usually the first win is deleting something safely.
What changes for your team
One place to look when something breaks, one set of tests, and onboarding a new EHR stops depending on which engineer is free. We've done exactly this at 52 connections.
None of these sound like you? Say so on the call — we'll tell you honestly if it's work we should take.
The shape of the problem
One Interface for Your Product. Thin Adapters Underneath.
Build each EHR into your product and every new one is another copy to maintain. Put a shared model in between and your product only ever learns one interface.
Adding the sixth EHR means writing one adapter — not touching your product. That is the difference between a quarter and a fortnight.
A buyer's view of the majors
They Are Not Equally Hard.
Not a feature comparison — what each one actually means for your calendar and your risk. For the sandbox paths and programme mechanics, see the EHR integration reference.
Platform
What it takes to get in
The thing that bites
Epiclargest US footprint
Free developer programme and sandbox. Build and test at no cost.
You go live per customer. Each hospital decides and reviews separately — winning one doesn't unlock the next.
Oracle Healthformerly Cerner
Developer console and sandbox, with its own registration and review.
Platform direction has been moving. Confirm current API versions before you scope — assumptions age badly here.
MEDITECHstrong in community hospitals
Modern API surface on newer versions; older sites are a different conversation.
Which version your customer runs changes everything. Ask before promising a date.
athenahealthambulatory-heavy
Developer portal and marketplace listing route.
Per-customer connectivity arrangements can add weeks that have nothing to do with your code.
eCW · NextGen · Veradigmambulatory
Each has its own partner programme and its own commercial terms.
Programme fees and review timelines vary widely. Budget the paperwork, not just the build.
Programme details change — we track them, and we'll confirm what's true today for your specific customers before you commit to a date.
Direct or middleware
Both Are Legitimate. Here's the Honest Trade-Off.
We build native integrations and we onboard teams onto Redox or Health Gorilla when that's the better call. We don't resell either, so this comparison costs us nothing to write straight.
Factor
Direct integration
Middleware
Cost shape
More build effort up front, no per-transaction fee. Cheaper as volume grows.
Less build effort, ongoing subscription or per-transaction cost you don't control.
Time to the first EHR
Slower — you build and certify the connection yourself.
Faster — pre-built connectors get you live sooner.
Many EHRs at once
Slower per vendor, unless you build the shared model above.
Fast. Write once, reach many — this is what you're paying for.
Depth
Full access to whatever the EHR exposes, including deep write workflows.
Limited to what the connector supports. Edge cases can hit a ceiling.
Best when
One or few EHRs, deep workflows, or cost-sensitive at scale.
Many EHRs fast, a small team, standard read and write is enough.
Plenty of teams start on middleware and bring the highest-volume connection in-house later. That's a sensible path, and we'll help you plan for it rather than pretend the decision is permanent.
The part that decides whether any of it works
Five EHRs. Five Ways of Saying the Same Thing.
Even with everyone speaking FHIR, one system sends GLUC-F, another FBS, another “Glucose, fasting (serum)”. Same test. Until they become one thing inside your product, you have data you can store but can't act on.
A mapping is confirmed by a human once, then applied automatically to every message from that customer. The AI removes the searching, not the judgement.
Where it goes wrong
Six Ways These Projects Fail.
None of them are exotic. All of them are avoidable if someone has seen them before.
01
Selling before scoping
A date promised on the assumption that "it has an API". The API exists; the customer's review queue is the actual timeline.
What we doConfirm the real gating steps before you commit publicly.
02
Registrations that lock
Some vendor registrations can't be edited once marked production-ready. Getting scopes wrong means starting the review again.
What we doDesign scopes and structure once, correctly, before anything is locked.
03
The second EHR copy-paste
The first integration gets duplicated for the second vendor. By the third, three copies drift apart and each needs its own fixes.
What we doOne shared model with thin adapters, from the second EHR onwards.
04
Unmapped codes
A code nobody mapped arrives. The record is stored but invisible to your alerting, and nothing errors.
What we doFlag anything unrecognised for review instead of silently accepting it.
05
Failing the security review
The build is done, then a hospital's security questionnaire finds gaps that take weeks to close — after the date.
What we doBuild to the review's expectations from the start, and help you answer it.
06
Nobody watching
A connection stops and raises no error. Your customer notices before you do, and it becomes a trust problem.
What we doAlert on the absence of data, not only on errors.
What you can buy
Five Ways to Start.
Fixed scope and fixed price, except the last, which is monthly.
02
Most chosen
First EHR live
One vendor, one customer, in production — through their programme and their review.
2–4 monthsFixed price
03
Multi-EHR layer
The shared model and adapters, so the next vendor is weeks rather than a quarter.
6–12 weeksFixed price
04
Consolidation
Existing integrations brought behind one model, one at a time, nothing going dark.
Per connectionFixed price
05
We hold the pager
Monitoring, the customer conversations when something breaks, and a monthly note.
MonthlyPer connection
Cost & timeline
What It Takes, and What Moves the Date.
Ranges from projects we've delivered. You get a firm number after one scoping call, before committing to anything.
Scope
Typical
What moves the date
Read-only, one EHR, one customer
2–4 months
The vendor's programme and the customer's security review — not the build.
Read and write
4–8 months
Writing into a clinical record means more scrutiny and more testing.
The multi-EHR layer
6–12 weeks
How consistent your own data model is today. This is the work that pays for itself.
Each customer after the first
+ weeks each
Their review queue, repeated per organisation. The number to drive down.
Keeping it running
ongoing
Vendors change APIs and customers upgrade. Monitoring, and someone who answers.
Fixed price agreed before we start, or a dedicated team by the month. Either way the code, the repository and the documentation are yours.
Proof, not promises
Three We've Delivered.
Consolidation
52 connections brought behind one model
A decade of separate integrations moved onto a shared model in waves, with both paths running during each switchover. No interruption to care.
52
connections
0
downtime
Multi-vendor
Independent hospitals, kept in step
Facilities sharing no infrastructure and no vendor, with patient data consistent across all of them — reconciled continuously rather than overnight.
Live
not overnight
Multi
vendor
The high bar
Passed what certification tests against
A server that cleared all 47 federal certification tests — the same bar software must meet to run inside a certified EHR.
47/47
tests passed
First
submission
FAQ
The Questions That Actually Get Asked.
If yours isn't here, it's a better use of a call than an email.
What's the difference between EHR and EMR integration?
Commercially, almost nothing — the terms are used interchangeably in buying conversations, and the work is the same. Strictly, an EMR is one organisation's record and an EHR is meant to travel between them. If a prospect uses one term over the other, follow their language rather than correcting it.
Which EHR should we integrate with first?
Whichever your nearest signed customer is on — not the one with the biggest market share. A live reference at one hospital is worth more in your next sales conversation than a half-built integration with a bigger vendor. Once one is live, the second is a much easier decision because you'll know your own numbers.
Do we need to be in a vendor marketplace?
Usually not to go live. A customer who has licensed your product can typically authorise you directly. Marketplace listings help customers discover you and lend credibility, but the real gate is each customer's own authorisation and security review — not the listing.
Will this slow down our product roadmap?
That's usually the real reason teams bring us in. The work is interrupt-driven with external dependencies you can't control, and it eats the engineers you least want interrupted. We either take it off your roadmap entirely or work alongside your team and hand over — your call, and we'll tell you which we'd recommend.
Do we get locked in?
No. It's built in your environment and your repository, and you get the source and the documentation. Ongoing support is something you choose because it's easier, not because you have no alternative. Teams do take it back in-house, and that's a fine outcome.
How do you handle patient data?
It stays in your environment. Encrypted in transit and at rest, every access logged, built and tested against synthetic data rather than real records, and handled to your retention policy. We're ISO 27001 certified, go through client security reviews regularly, and will sign a BAA.
Tell Us Which EHRs Your Customers Are On.
You'll get a straight answer on whether your date is realistic, roughly what it costs, and whether direct or middleware is the better call for you. Before anyone talks about a contract.
+1 (669) 649 0706
hello@nirmitee.io
USA
Iselin,
NJ 08830
India
Baner, Pune,
Maharashtra 411045
Thanks — we've got it.
You'll hear back within one business day, from someone who has done this before.