EHR Integration Due Diligence: The Questions That Decide the Timeline

Because integration is where the schedule actually lives. Product selection takes weeks. Integration takes quarters, and it is the part nobody costs properly.

The pattern repeats across deployments. A practice picks a tool in a month, signs in six weeks, and then spends two quarters waiting for a connection that was described in the sales process as available. The word doing the damage is usually available, which can mean listed in the app store and installable this afternoon, or can mean we have built to that API and no customer has yet turned it on with your version.

The questions below are designed to make that distinction impossible to blur. They are also worth asking before the shortlist rather than after, because integration depth is one of the few criteria that legitimately removes vendors from consideration. Our per-system pages, starting with Epic and Oracle Health, cover what each vendor's programme actually requires, and the full set is indexed at the EHR integration hub.

It matters, though not in the way the marketing implies. FHIR is a standard, not a guarantee of access, and every major EHR vendor also exposes proprietary interfaces that do things FHIR does not.

The distinction that matters most is read versus write. Reading context out of the chart is comparatively easy and widely supported. Writing a note, an order or a document back into the chart is where value concentrates and where access is gated. Ask for the read list and the write list separately, because a vendor that says it integrates with your EHR is frequently describing read-only access.

ASTP/ONC certification criteria require certified health IT to expose standardised API functionality, which is why FHIR read access has become broadly reliable. Note that the certification landscape is itself in motion: a deregulatory proposal published in December 2025 would eliminate a large share of existing certification criteria, and it had not been finalised as of August 2026. The current position is tracked in the regulation tracker.

That the vendor completed a programme, which is genuinely useful, and not that your instance can install it tomorrow.

Each major EHR vendor runs a partner or marketplace programme with its own review, technical validation and commercial terms. A listing means the integration has been built and reviewed against that programme. It does not tell you whether your version supports it, whether your organisation has the relevant module licensed, or whether your EHR vendor's team has capacity to enable it this quarter.

Three questions get you past the badge. Is the vendor listed today, or applying? Ask for the listing URL. How many customers are live on this integration with our EHR, and may we speak to one? And what is the shortest and longest time to production among those customers? The gap between shortest and longest is the honest estimate of your own timeline.

Timelines vary widely by EHR vendor and by what you are asking for. Read-only connections through a standard programme are routinely faster than write-back into the chart, and write-back into a hospital instance is slower than the same integration into an ambulatory one. Rather than trust a generic figure, ask the vendor for the range across its own live customers, and ask your EHR account team the same question independently. Where the two answers differ materially, believe the EHR vendor. Per-system detail sits on athenahealth, eClinicalWorks and NextGen.

Four questions that separate a built integration from a demonstrated one.

1. Do you have sandbox credentials for our EHR today, and how long did it take to get them?
2. Have you tested against our EHR version, and can you name it?
3. What has to happen on our side, and who at our EHR vendor has to be involved?
4. Who owns the connection when it breaks after an EHR upgrade?

Question two catches more problems than the others combined. EHR versions differ in what APIs they expose, and a vendor that has integrated with the current release may not have tested against the version you are running. Ask for your version number to be named back to you.

Question three is the one that produces the schedule. Almost every meaningful integration requires work from your EHR vendor: enabling an app, provisioning credentials, configuring a client. That work sits in someone else's queue, and it is the dependency that turns a six week project into a six month one. Find out early who is in that queue and what it takes to get on it.

Question four is a contract question disguised as a technical one. EHR vendors upgrade on their own schedule and integrations break. The useful answer names an owner and a response time. The unhelpful answer is that upgrades rarely cause issues, which is a prediction rather than a commitment.

One of three parties, and you should know which before signature rather than after.

The AI vendor may absorb it, which is common where the integration is a standard app store listing already built. You may pay a one-off implementation or integration fee to the AI vendor, which is normal at the enterprise end and should appear in the order form rather than arrive later. Or you may pay your EHR vendor, through interface fees, module licences or professional services, and this is the cost most often missed because it lands on a different budget line and sometimes in a different department.

Ask three direct questions. What is the total one-off cost of getting to production, from all parties. Which of those costs are quoted and which are estimated. And does anything recur annually, such as an interface maintenance fee or a per-connection charge from the EHR vendor.

Then ask your EHR account team the same question independently, without the AI vendor in the room. The two answers are frequently different, not through dishonesty but because each party knows its own side of the fee schedule. The difference between the two is the number that should go into your business case, and it belongs in the model before you run the ROI calculation rather than after.

Then the questions are the same and the answers are thinner, which is useful information rather than a problem.

AI vendors build integrations where the customers are, so the depth available on Epic and Oracle Health is generally ahead of what is available on MEDITECH, Veradigm or a smaller specialty system. That does not mean nothing works. It means the honest answer for your system is more often a standard FHIR read plus copy and paste, or an extension, than a native write-back, and you should price the product on that reality rather than on the roadmap.

Two things to do differently. Ask the AI vendor how many customers it has live on your specific system, and if the answer is zero, negotiate as a first customer: a discount, a shorter term, and a written date. And ask your own EHR vendor what its partner programme requires, because in some systems the constraint is programme capacity rather than technology, and your account team can sometimes move it.

The third option, which is underrated, is to choose a workflow that does not need deep integration. Ambient documentation with copy and paste is genuinely workable at small scale. A phone agent that reads the schedule and writes nothing back can deliver most of its value through a lighter connection. Picking the workflow to fit the integration reality is usually cheaper than forcing the integration to fit the workflow.

Five, in rough order of how expensive they turn out to be.

1. Integration described without a method. If the vendor cannot say FHIR, proprietary API, HL7 or extension, there is no integration yet. There may be a plan.
2. No named live customer on your EHR. Being the first customer on a connection is a legitimate choice, at a discount, with a longer timeline written into the contract. It is not a legitimate surprise.
3. Write-back promised on the roadmap. Roadmap write-back is a future you are paying for now. Price it as read-only until it ships, and put a date and a remedy in the contract.
4. Screen automation presented as integration. Sometimes the right pragmatic answer, particularly where no API exists. But it must be disclosed, it must be checked against your EHR agreement, and it must be priced as the maintenance liability it is.
5. Silence on upgrade breakage. No named owner and no response time for a post-upgrade failure means the clinic that breaks on a Monday morning is your problem.

None of these should automatically disqualify a vendor. All of them should change what you sign: a shorter term, a milestone-linked payment, or a written commitment with a date attached. The other half of the diligence, on data handling and the business associate agreement, is in the fifteen vendor questions.

Second, immediately after the compliance screen and before the demo. That ordering saves the most time, because both screens remove vendors on paper.

A workable sequence: screen on compliance posture, screen on integration method and evidence, demo the two survivors, pilot one, and only then negotiate. Most organisations reverse the middle two, demo four vendors and discover integration constraints in week nine, by which point a clinical champion has a preference and the constraint becomes a negotiation rather than a fact.

Write the integration answers into the contract, not the notes. A named method, a named EHR version, a date for production, and a remedy if it slips. Vendors who have done this before will accept that language because they know their own timeline. Vendors who have not will resist it, which is itself the answer to the question you were asking.

Two final links worth having open while you do this. The HIPAA-compliant AI tools shortlist records what each vendor publicly documents, including integration claims, and the ambient documentation page describes where write-back actually changes the workflow rather than just the demo. If you would rather have someone run the diligence with you, the vendor selection engagement produces the scored comparison and the integration feasibility note for your specific estate, and the deployment roadmap is what turns it into a sequence with dates.