Most EHR integration proposals are indistinguishable because they are written to be, and the way to tell firms apart is to ask questions that only delivery experience can answer. Ask which specific surfaces they have worked with rather than which vendors — Epic’s App Orchard versus Interconnect, Oracle’s Ignite APIs versus Open Integration — because naming the surface correctly is a low bar that screens out a surprising number of firms. Ask whether they have worked in a client’s production environment or only a public sandbox, since almost all the real friction lives in access, credentialing and governance rather than in code. Ask what they do when a governance review rejects a scope, or when the client’s analyst stops responding, because both will happen and the answer reveals whether they have been there. And treat a fixed-price quote produced without access to the client’s environment as a red flag rather than a convenience.
Why Integration Proposals All Look the Same
I’ll be straightforward about the position this post is written from: it’s a guide to evaluating firms like ours, written by one of them. That’s only credible if it’s genuinely useful to someone who reads it and then hires a competitor — so that’s how I’ve written it. Most integration proposals in this space read nearly identically because the language that sells (“Epic experience,” “FHIR expertise,” “proven track record”) is cheap to write and expensive to verify — which is exactly why it’s worth learning to verify it yourself.
Ask About Surfaces, Not Vendors
Anyone can claim “Epic experience.” Far fewer can correctly name which surface they actually used — Epic’s App Orchard (now Epic Showroom) for distribution versus Interconnect for the underlying FHIR API access, or on Oracle’s side, Ignite APIs for FHIR versus Cerner Open Integration for HL7 v2. Naming these correctly and specifically is a genuinely low bar, and it’s remarkable how many proposals fail it. I go through what each surface actually involves in the Cerner build process, the Epic-vs-Cerner difficulty comparison, and the athenahealth marketplace path — use those as a reference for what a competent answer should actually sound like.
Production Experience vs. Sandbox Experience
This distinction matters more than years in business, and it’s worth asking about directly rather than assuming a firm’s tenure answers it. Sandbox experience teaches API mechanics. Production experience teaches everything else this site’s integration posts keep coming back to — environment access and sponsorship, governance review, credentialing timelines, cutover planning, and what actually happens when a client’s real, messy configuration doesn’t match the sandbox’s clean synthetic data. A firm that’s only ever built against public sandboxes hasn’t learned the part of the job that actually determines your timeline.
The Questions That Reveal Delivery Experience
This is the core utility of the post — ten checkable questions, with what a real answer sounds like:
- Which specific surfaces have you built against? A real answer names them precisely, not “Epic and Cerner.”
- Have you worked in a production environment, or only a sandbox? Ask for a specific, nameable example.
- Who handled credentialing or access sponsorship on your last project? A real answer describes an actual process, not a vague “we handle it.”
- What happened when a governance review rejected a scope you requested? Everyone who’s done real work has a story here.
- What do you do when the client’s analyst goes quiet for weeks? This will happen on your project too.
- How do you handle a data-quality problem discovered mid-build? Not “we don’t have those” — that’s a red flag itself.
- What’s your read-vs-write experience split? Write-back is a different and harder problem, covered in our write-back post.
- How do you scope before you have environment access? The honest answer is “conservatively, with contingency” — not a confident fixed number.
- What happens after go-live? Ongoing maintenance is real; a firm with no answer here hasn’t shipped anything long-term.
- Can you name a project that didn’t go as planned, and what you did? Nobody’s record is perfect. The answer to this question is the tell.
Red Flags in an Integration Proposal
High-utility and genuinely costs us nothing to publish, because a firm that fails these checks was never our competition anyway:
- A fixed price quoted without any environment access. Nobody can price real integration risk without seeing what they’re integrating with.
- No mention of credentialing or governance in the timeline. If access sponsorship isn’t a named line item, it wasn’t planned for.
- The client’s own analyst treated as out of scope. They’re on the critical path whether the proposal accounts for that or not.
- “We’ll use FHIR” with no discussion of what the actual workflow needs. The standard doesn’t matter if nobody’s checked what the workflow requires from it.
How Integration Work Should Be Priced
Discovery-first, phased pricing is the structure that reflects reality here — not because it’s convenient for the vendor, but because nobody can honestly price environment access, governance timelines and data quality before they’ve actually seen the client’s environment. A firm quoting a confident fixed number before any of that is either underpricing the risk or hasn’t thought about it. I won’t quote our own rates here — the point is the structure, not a number.
Worth knowing the stakes: KLAS Research has found that only about 38% of organizations report their recent EHR implementation fully met expectations — a real, sobering number that supports discovery-first pricing over a confident fixed quote produced sight-unseen.
Who Owns What: A Responsibility Map
| Task | Vendor | Client | EHR vendor |
|---|---|---|---|
| Environment access sponsorship | ✓ (critical path) | ||
| Technical build | ✓ | ||
| Governance/clinical review | Supports | ✓ | Reviews |
| Interface analyst availability | ✓ (critical path) | ||
| Ongoing API/version changes | ✓ | Drives |
A proposal that treats the client’s own analyst and administrator as outside the project timeline is underestimating the project — they’re on the critical path in almost every real build described across this site’s integration posts.
Next Steps
Use the ten questions above on us too — that’s the honest test of whether this post is worth anything. If you’re evaluating an EHR integration partner and want a second, technical opinion on a proposal you’ve already received, or you’re ready to talk to our EHR integration team directly, reach out. And if you’re still deciding which vendor to integrate with in the first place, our full Epic vs. Cerner vs. athenahealth comparison is the right starting point.