What really causes healthcare software project delays in 2026
TL;DR
Healthcare software project delays are rarely an engineering failure. They come from work on your side that nobody put on a schedule: approvals, content, data, system access, and the start date itself. The regulatory calendar makes 2026 a bad year to learn that. Impacted payers owe three new APIs by January 1, 2027, and in a February 2026 survey only 16% expected to be 75% to 100% done by then.
- Put every client side input on the plan with a named owner and a date.
- Treat an API you do not control as a priced risk, not an assumption.
- Agree in writing what moves when an input lands late, in both directions.
- A missing start date blocks the contract before it blocks the build.
The delay postmortem usually blames the wrong party
Ask why the release slipped and you get an answer about engineering. Underestimated complexity, a hard integration, QA found too much. Sometimes true. More often the schedule was gone before anyone wrote code.
The baseline is worse than most buyers assume. In PMI's 2025 Pulse of the Profession, a survey of 2,841 project professionals, the share of projects finishing inside their original timeline was 63% for respondents with high business acumen and 59% for the rest. Close to four in ten miss, by the account of the people running them.
Healthcare makes it structural. The VA Office of Inspector General found the Electronic Health Record Modernization program did not meet the standards for a reliable schedule, with known tasks missing from the schedules, and projected that delays extending the program would likely cost about $1.95 billion in overruns per year.
The January 1, 2027 API deadline is already running late
If your 2026 roadmap depends on a payer API, the clock is public. The CMS Interoperability and Prior Authorization Final Rule requires impacted payers to implement the Provider Access API, the Payer-to-Payer API and the Prior Authorization API by January 1, 2027, and to carry prior authorization information, drugs excluded, in the existing Patient Access API by the same date.
The industry is behind. In a February 2026 WEDI survey of 86 respondents, 35% of payers put themselves at 25% complete or less on the Patient Access API, and only 16% expected to reach 75% to 100% by the deadline. Among providers, 33% had not started. By WEDI's October 2025 reading, provider confidence in the date had fallen 22 points against its first survey, from 69% to 47%.
Read that as a dependency forecast. If your product consumes one of those APIs, your schedule inherits their readiness.
How we put this list together
Three rules, applied to every item below.
- Each dependency has stopped or repriced a healthcare build of ours, named in our own pre-build notes.
- Each is owned by someone outside the delivery team, which is what hides it from an engineering estimate.
- Where we state our own numbers, any group with fewer than three data points is not published.
One disclosure. Mercury Development sells healthcare software development, so the examples are our own work.
The four client side dependencies at a glance
| Dependency | Who owns it | What it costs when it slips | What belongs in the plan |
|---|---|---|---|
| Approvals and decisions | A named business owner | Sprint cadence, then velocity | A decision deadline per sprint |
| Content and data | Content, clinical or data owner | Rework and idle design time | Batch dates plus a format spec |
| Client owned APIs | The client's own API team | Budget and schedule both move | A frozen version and contract tests |
| Start date | Procurement and legal | Nothing begins at all | A date in the agreement before signature |
Approvals: the queue nobody scheduled
Two week sprints assume decisions arrive inside two weeks. That assumption is a dependency, and it is almost never written down.
We have run portal work where task approval delays broke sprint planning outright. The team was not blocked on code. It was blocked on someone with authority confirming what to build, while the sprint boundary arrived anyway. You lose the cadence first, then the estimate.
Underneath it is ownership. In one care operations migration the buyer called the June target impossible and, in the same conversation, said they had nobody free to coordinate the work internally. Both were accurate. A hard date with no internal owner is a forecast, not a plan.
Content and data: late, partial, wrong shape
Content looks like the easy part of a healthcare build. It is the part most often late, and lateness is not the expensive failure. Wrong shape is.
On a patient education app we flagged late prerequisites, incorrect data formats and partial content delivery as cost and schedule risks before build. All three are one problem: screens get built against assumed structure, real content arrives in another, and the work is done twice. Nobody logs that as a client delay. It arrives as a design change request.
Operational data behaves the same way. A payer outreach program we looked at could not run because enrollment files carried bad phone numbers. The software was fine. The input was not. Agree the format before the first batch, with a sample record that validates.
The phone number problem has its own breakdown in our guide to health plan member outreach, which puts data cleanup in the first sprint.
Client owned APIs: the integration you cannot test
An API you do not own is the dependency most likely to move your budget rather than only your dates.
On a hospital engagement app we warned the client that unstable client side APIs could move both. A late API costs you waiting time. A changing API costs you rework on everything already built against it.
Then there is access. We have had clients decline to hand over source code for the system we were extending, and others whose IT held back environment access during a release freeze. Both are legitimate internal decisions. Both make an accurate estimate impossible, and pretending otherwise turns a fixed bid into a dispute.
Ask for a frozen version, a sandbox, and contract tests you can run on your own schedule. If none of the three exists, that part of the project is time and materials, and the proposal should say so.
How the split between fixed bid and time and materials plays out in a contract is covered in our comparison of healthcare software engagement models.
The start date: one empty field that holds the contract
The smallest dependency here is a single field, and we have watched it stop everything. One client told us plainly they could not execute the master services agreement without a start date. Not a scope problem. Not a price problem. A blank field.
It happens because the date sits between two groups who each think the other owns it. Delivery assumes procurement sets it on signature. Procurement cannot sign a term with no beginning. Meanwhile the team you reserved is offered elsewhere, and the quoted dates quietly expire.
Put a target start date in the proposal, and state how long the staffing hold lasts.
Writing dependencies into the plan and the contract
Buyers are right to want remedies when a vendor misses. The useful version of that clause runs both ways, because a one way penalty gets priced back in as padding.
Four clauses do most of the work.
- A dependency register in the statement of work: each client side input, its owner, its due date, and the task it unblocks.
- A decision service level: how long an approval may sit before the schedule moves, in business days.
- A symmetrical consequence: vendor slip triggers vendor remedy, client slip triggers a dated schedule change rather than a quiet overrun.
- Change control that counts input changes. A data format rewritten after build is a change, whatever it is called.
None of this is adversarial. It replaces an argument about blame with arithmetic about dates.
To check whether a vendor counted these dependencies in the first place, read the bid with our guide to the software development timeline estimate.
Which dependency is your real risk
An integration governed by a regulatory deadline: the API is your risk. Freeze the version and keep a stub path, so the team is never idle when the other side slips.
A content heavy patient or member product: the handoff is your risk. Lock the format and batch calendar before design.
An enterprise buyer with a committee: approvals are your risk. Buy a decision owner with authority, not a weekly status meeting.
A first project with a new vendor: the start date is your risk. Everything downstream is quoted from it.
What our own healthcare discovery records show
These are our own numbers, counted by hand from healthcare and telehealth discovery records. They describe only what our pre-build notes wrote down.
In around 20% of those engagements our notes named a client controlled technical prerequisite as a cost or schedule risk before any build started. Around 15% involved client owned APIs, environments or source code we could not reach or rely on. Around 10% involved content and operational data that arrived late or in the wrong format.
Read that as a floor, not a prevalence estimate. The practical finding is simpler than the percentages. When the client side was ready, delivery was fast: a Burger King campaign platform shipped in under a month from first contact, and the MatchedFlicker imaging application moved from Windows desktop to HIPAA compliant online access in three months.
The honest limit of dependency management
Opinion, stated plainly. Dependency tracking does not make a bad date achievable. It makes the date honest earlier, which is worth more than it sounds and less than buyers hope for.
Two limits are real. Code genuinely is the bottleneck sometimes: on Fitbit we spent two months deciphering a vendor's proprietary Bluetooth implementation, and no register would have shortened that. And a register does not create authority. If the person who can approve has no time, writing down that approvals are late produces a very well documented delay.
The failure mode we see most is a plan that models only vendor work. Every task has an owner and an estimate, and the client column does not exist. That plan will be wrong in one direction. The workflow automation system we have maintained for a medical billing client since 2006 is on its fourth major release for the opposite reason: every input and approver had a named owner on the client side.
Written by Alexey Rodionov, Lead Front-end Developer at Mercury Development since 2020. Alexey is a Google Developer Expert in Web Technologies and a Chromium contributor whose code ships in Chrome DevTools, Google's Bubblewrap and Microsoft PWABuilder. The integration reviews and environment assessments behind this article's dependency findings come from the front-end practice he leads.
Send us the dates you promised and the ones you depend on
Tell us what you committed to externally, what has to come from your side, and who owns each piece. We will come back with the plan we would run and which dates will move.