Most big tech programs miss at least one target. Here’s what EHR integration discovery should leave you holding before you sign anything.
Here’s a number worth knowing before you sign an integration contract. In 2024, BCG asked more than 1,000 executives about their large tech programs, and more than two-thirds of those programs weren’t expected to come in on time, on budget or within the scope they started with. Among the ones that missed on all three, over 60% named the lack of an end-to-end plan as part of the reason (BCG, 2024).
Healthcare IT isn’t immune to this. So this piece is about the step that’s supposed to catch problems while there’s still no contract: discovery. What it should leave you holding, how to tell when it was done for show, and how we handle it at Itirra.
Key takeaways
- What it is: EHR integration discovery is a short, paid phase before the build. You come out of it with a plan you can actually hold a vendor to.
- The numbers: BCG (2024) found that more than two-thirds of large tech programs aren’t expected to land on time, on budget and in scope. Over 60% of the worst performers named the lack of an end-to-end plan.
- In healthcare: only 38% of organizations told KLAS (2025) that their recent EHR implementation hit the mark.
- What you should walk away with: eight things, from a workflow map with real timings to a tested API list, named risks and a phased estimate.
- Two warning signs: a fixed price before anyone has seen your systems, and a discovery that ends with slides.
- How we do it: usually 10 to 40 hours of scoping, with our CTO involved from the start.
What is EHR integration discovery?
EHR integration discovery is the short, scoped piece of work that happens before anyone builds anything. Your team and ours map how the work actually gets done today, figure out which integration path makes sense, check which data and APIs your EHR really exposes in your environment, and write it all down as a scope, a risk list, acceptance criteria and an estimate. The idea is simple: make the expensive decisions once you know the facts, not before.
In any serious EHR integration consulting engagement, it comes first. It’s not the sales call, and it’s not the build either. It sits in between, and in our experience it’s the step that most often gets rushed, skipped, or quietly turned into a presentation.
What happens when you skip discovery?
Most of the time, nothing dramatic happens. The project just ends up costing more, taking longer and delivering a bit less than the slide said.
And these aren’t old numbers. In the same 2024 BCG study, only 30% of large-scale programs met their timeline, budget and scope expectations. PMI’s research from the same year, with nearly 10,000 project professionals across 139 countries, rated 48% of projects as successful and 12% as outright failures, with the other 40% somewhere in the middle. PMI’s bar for success, by the way, isn’t “on time and on budget”. It’s whether the result was worth the effort and money that went into it (PMI, 2024).
Hospitals don’t do better. KLAS looked at EHR implementations, which are about as big and as carefully planned as hospital IT projects get. In its 2025 report, only 38% of organizations said their recent implementation hit the mark, and 40% reported significant misses. One of the causes KLAS points to is expectations that didn’t line up between the health system, the vendor and the implementation partner. Its advice includes measuring your baseline before you start (KLAS Research, 2025).
An integration is a smaller project than a new EHR, but it has traps of its own. What your EHR will let an outside app read, write or trigger depends on the vendor, the version and how your instance is set up. Some of the timeline isn’t yours to control at all: in our experience, an EHR vendor’s app review can take anywhere from days to months, and nobody outside can hurry it along. (Where the EHR is heading next adds a few more items to that list.) A plan that doesn’t account for this has a launch date that’s mostly wishful thinking.
The best-known example of building first and working out the details later is probably still Healthcare.gov. When the GAO reviewed it in 2014, it found the core contracts had been issued “when key technical requirements were unknown” (GAO-14-694). That was more than a decade ago, and judging by the surveys above, the habit is doing just fine.
Over the years we’ve noticed that the timing of a surprise matters more than the surprise itself. Here’s a common one.
8 Things Discovery Should Hand You
Each of these answers a question you’d otherwise end up answering halfway through the build, when every change costs more.
1. A map of the workflow as it really runs
Not the version in the process document. The real one: who does what, in which system, at which point the work leaves the EHR for a phone call, a fax or someone’s spreadsheet, and how long each step takes. That’s your baseline. Without it, there’s no way to show later that the project made a difference, including to the people who sold it to you.
2. The integration path, and why the others lost
There’s usually more than one way to connect: an app that launches from inside the EHR, a backend API connection, an HL7 v2 interface, file exchange, or an integration platform in the middle. We walked through these in Keep the EHR. 5 Ways to Fix the Workflow. and compared SMART on FHIR and backend integrations in more detail. On first calls we usually lay all of them out and say which ones we’d rule out for you, and why. A good discovery does the same thing in writing. If nobody can tell you why an option was dropped, the decision probably wasn’t really made.
3. The exact list of data and APIs
Which FHIR resources you need, whether you read or write them, which events matter, and which permissions (scopes) the app will ask for. All of it checked against what your EHR actually exposes in your environment, ideally in a sandbox, rather than taken from a brochure. It’s worth asking for a little more than you think you need, because adding permissions later usually means going through approval again. Planning read-only access when the workflow really needs write-back is one of the most common EHR integration mistakes we see.
4. Architecture and where it runs
Something your security team can read without needing a meeting to understand it. Where the solution runs (often in your own cloud), how it authenticates, where PHI goes and where it never goes, what happens when a call fails and has to be retried, and who gets alerted when something breaks. If your security review is going to ask about it, discovery should already have the answer.
5. Scope and a statement of work, including what’s out
What goes into the first release, what waits for later phases, and what isn’t part of the project at all. That last list is the one people tend to skip, and it’s the one that saves the most arguments down the road. Add a change control process too: how a new requirement gets reviewed, priced and approved, so the scope can change without the project slowly drifting somewhere nobody agreed to.
6. Risks and dependencies, each with a name next to it
Vendor app review and listing. Approvals and interface work on the hospital IT side. Patient matching. Whether writing back to the EHR is allowed at all, and whether it’s safe. Each of these needs an owner and a plan B. A simple example: if the direct integration isn’t approved by launch, staff can type in a patient identifier and the rest of the data loads on its own. It’s not elegant, but the launch doesn’t end up waiting in someone else’s queue.
7. Acceptance criteria tied to the baseline
How you’ll know it worked, measured in things your team already tracks: hours, days, number of touches, errors. Plus who deals with the exceptions once it’s live. If there’s nothing measurable, there’s nothing to sign off on, and a project can stay “almost done” for months.
8. An estimate and an EHR integration roadmap you can hold someone to
A cost range that comes from the scope above, not from “a similar project we did once”. Split into phases so the first release actually delivers something, and so the riskiest dependency gets started first instead of last.
EHR integration discovery checklist
Something to bring to your next vendor meeting. If a row comes back empty, it’s worth asking why.
| # | Deliverable | The question it answers | If it’s missing |
|---|---|---|---|
| 1 | Workflow map + baseline | How does the work run today, and how long does it take? | No way to prove the project worked |
| 2 | Integration path | Which way do we connect, and why not the others? | The choice gets made mid-build, by default |
| 3 | Data and API list | What exactly do we read, write and trigger? | Surprises when the EHR says no |
| 4 | Architecture | Where does it run, and where does PHI go? | Security review stalls the launch |
| 5 | Scope + SOW + change control | What’s in, what’s out, how do changes get approved? | Scope drifts, invoices grow |
| 6 | Risks with owners | What can stop us, and who handles it? | Delays nobody planned for |
| 7 | Acceptance criteria | How do we know it’s done and working? | “Almost done” for months |
| 8 | Phased estimate and roadmap | What does it cost, in what order? | A number with nothing behind it |
5 red flags that your discovery didn’t do its job
Any one of these usually means the “discovery” was really a sales step under a different name.
- A full fixed price before anyone has looked at your systems. Either the risk is baked into the price, or nobody priced it at all. Either way, it lands on your side.
- The deliverable is a slide deck. Slides are good at selling a vision. What you need is a scope, an API list and a risk register.
- There’s no out-of-scope list. Whatever isn’t written down tends to get argued about later, usually at hourly rates.
- Not a single named risk. Every EHR integration depends on people outside the project team. If the plan lists no risks, it probably didn’t look very hard.
- No baseline. Without “before” numbers, any claim about “after” is just an opinion.
Building a health tech product that has to live inside the EHR?
If you’re a health tech startup or a product team, everything above still applies. Add two more things: the marketplace timeline, and what installation looks like for your customers’ IT teams.
The EHR vendor’s marketplace has its own sequence: building the app, testing, submission, publication, and then getting your first customer site live. Discovery should put each of those on a timeline that runs on the vendor’s clock, not yours. Then think about the install from the hospital’s side. A FHIR app usually means less work for hospital IT than a custom interface, but less work still needs a plan. One pattern we keep running into: hospitals want the work to happen inside the EHR, so a product that lives next to it eventually has to move in. There’s more on this in our guide to FHIR integration consulting for healthcare startups.
How we run discovery at Itirra
We start with a fixed block of scoping work, usually somewhere between 10 and 40 hours, and our CTO is part of it, not someone who reads a summary afterwards. At the end you have the eight things above, and you decide what happens next.
It isn’t free pre-sales work, and it isn’t the build. We map how your data moves today, pick the integration path and the exact APIs, write the scope and the statement of work, and get the EHR vendor registration started early, since that part runs on the vendor’s schedule. We’d also rather tell you up front which steps will be slow than have you find out after you’ve announced a launch date.
Then you make the call on the next phase with a real scope, a real plan and an estimate in front of you, instead of a guess. If you decide to build with us, you own what we build, and that’s in the contract. And if you’re talking to more than one partner, here’s what to look for in a FHIR development partner.
One question tends to come up right after discovery: should we build this at all, or just subscribe to something that already exists? We’ll get into that on November 16.
Sign the build contract. Just not first.
Frequently Asked Questions
What is EHR integration discovery?
It’s a short, scoped phase before the build. It maps how the work runs today, picks the integration path, confirms which data and APIs your EHR actually allows, and ends with a scope, a risk list, acceptance criteria and an estimate.
What are the deliverables of a discovery phase?
Eight things: a workflow map with a baseline, the chosen integration path, the data and API list, the architecture, the scope and SOW (with an out-of-scope list and change control), risks with owners, acceptance criteria, and a phased estimate with a roadmap.
How long does EHR integration discovery take?
That depends on how many systems are involved and how much your team already knows. At Itirra we usually start with a fixed block of 10 to 40 hours of scoping work.
Can we skip discovery if we already know what we want?
You can, but the same work still has to happen. It just happens during the build, at build prices. Knowing what you want is the starting point. Discovery checks whether your EHR, your approvals and your timeline agree with you.
What’s the difference between discovery and a statement of work?
The SOW is one of the things discovery produces. Discovery also gives you the workflow baseline, the API list, the architecture, the risk list and the acceptance criteria, which are what make the SOW realistic.
What should we ask a healthcare integration consultant before signing?
Which APIs they’ve tested in your environment, who owns each risk, what’s out of scope, how changes get approved, and how success will be measured. If the answers aren’t written down, discovery isn’t finished.
Why do vendors give a fixed price before discovery?
Mostly because it closes deals faster. Without discovery, a fixed price either carries a large risk buffer or leaves the risk unpriced, and in both cases it ends up on your side of the table.
Who should be in discovery from our side?
Someone who does the work every day, someone who owns the systems (IT or integration), and someone who can approve scope and budget. Bring in security once the architecture is on the table.
What’s the one thing you wish you’d known before your last integration project started?
30 minutes, no pitch deck
Let’s talk about your project.
Think of the integration project you keep postponing because nobody could tell you what it would really take. That’s exactly what discovery is for.
Sources
- Most Large-Scale Tech Programs Fail. Here’s How to Succeed. Boston Consulting Group (Grebe, Lyon, Harnisch, Chatterjee, Kok, Brock), Nov 13, 2024. Source for two-thirds of large-scale programs missing time, budget or scope, the 30/35/35 split and the 60%+ citing no end-to-end master plan.
- Reframing Project Success. Project Management Institute, Sept 19, 2024. Source for 48% successful, 12% failed, nearly 10,000 respondents in 139 countries and the definition of success.
- EHR Implementations 2025. KLAS Research, Arch Collaborative (Anderson, Beyer, Tate), Jan 10, 2025. Source for 38% hitting the mark, 40% significant misses, misaligned expectations and baseline measurement.
- Healthcare.gov: Ineffective Planning and Oversight Practices Underscore the Need for Improved Contract Management (GAO-14-694). U.S. Government Accountability Office, July 30, 2014. Source for task orders issued when key technical requirements were unknown.