I'm going to make a prediction that most of the software vendors serving healthcare will disagree with, and I'll make it with confidence: the majority of the systems healthcare organizations run today will be functionally obsolete within five years.
Not broken. Not offline. Obsolete β in the way a flip phone was obsolete in 2010. It still made calls. It just couldn't do what the new generation could, and the gap widened every quarter until carrying one became a decision to fall behind.
We are entering a new stage of technology in healthcare, and how organizations buy β or build β software is about to change more in the next five years than it did in the last twenty. Here's the argument, and here's what I'd do about it if I were running any healthcare organization today.
Strip away the marketing and look at the architecture. The CRM your admissions team uses, the EMR your clinicians chart in, the RCM system your billers fight with β most of these are first-generation products. They were built to digitize paper: take the form, put it on a screen; take the filing cabinet, put it in a database; take the claim, transmit it electronically.
That was genuinely valuable. It was also twenty years ago, and the architecture reflects it. These systems were designed for humans to do all the work inside software that merely stores the results. They were never designed for software that does the work β drafting the note, verifying the benefits, assembling the authorization, auditing the chart β because when they were architected, that wasn't possible.
Now it is. And you cannot retrofit an architecture designed to store work into one designed to perform it. You can bolt an AI scribe onto a first-generation EMR β many vendors are doing exactly that β but the scribe lives beside the record, not inside it. The seams show up everywhere: data re-entered, context lost, workflows that are "AI-assisted" in the demo and manual in real life.
Here's the part vendors won't say out loud. A large share of the incumbent healthcare software category has traded into private equity ownership, and the incentive structure that follows is predictable. The playbook for a mature software asset is to maximize cash flow from the installed base: raise prices, cut R&D, consolidate support, and minimize investment that doesn't produce near-term margin.
That's not a conspiracy β it's just what harvesting a mature asset looks like. If you're a customer, you experience it as a familiar pattern: your bill goes up every year, meaningful new features slow to a trickle, the interface ages in place, and the "AI strategy" is a partnership press release rather than a rebuild. The product isn't being grown. It's being drained. And drained products eventually get consolidated or sunsetted β after the customers have funded the harvest.
The companies running this playbook will dispute this characterization. Watch their release notes instead of their press releases and decide for yourself. The question to ask about any system you depend on is simple: is the product being invested in for the next era, or monetized through its last one?
We are in the first stage of this shift, which is why it's still possible to underestimate. Today, AI-native platforms compress documentation time and automate the workflows around intake, utilization review, and follow-up. That alone changes the economics of running a healthcare organization β but it's the smallest version of what's coming.
The next stages are already visible: systems where AI agents execute entire workflows end-to-end with human supervision; where the operational layer of an organization β scheduling, compliance, billing, reporting β runs continuously rather than being pushed forward by human effort; where the software is less a filing system you operate and more an operating system that works alongside you. Each stage widens the distance between organizations on modern platforms and organizations on harvested ones.
Five years from now, the gap between a first-generation stack and a current one won't be a feature comparison. It will be a cost-structure difference β in labor, in denials, in compliance exposure, in staff retention β large enough to decide which organizations are viable.
Here's the conclusion most technology essays skip, and it's the one I actually care about: the winners of the next five years won't be determined by which software they pick. They'll be determined by whether their organization can execute change at all.
Every organization is going to face the same sequence of decisions: when to leave the legacy system, what to move to, how to migrate without chaos, how to retrain a workforce, and then β because the technology won't stop moving β how to do all of that again, and again. The organizations that treat each of these as a once-a-decade trauma will lose. The organizations that build change management as a repeatable competency will win, almost regardless of which specific platforms they choose along the way.
That competency looks like:
- Leadership that can sponsor change. Not tolerate it β sponsor it. Executives who communicate why, absorb the friction, and hold the course through the messy middle. If your leadership team cannot do this, that is the single biggest risk to your organization β bigger than any vendor decision. I'll say it plainly: organizations without leadership capable of executing change will not survive this transition.
- A workforce practiced at adoption. Teams that have successfully adopted new tools trust the next adoption. Teams that have only experienced botched rollouts resist everything. Every well-run change builds capacity for the next one.
- A real evaluation and migration muscle. Knowing how to scope a migration, protect your data, and cut over without losing your staff is a skill. Organizations that have it can move when the math says move. Organizations that don't stay trapped by their own fear.
- Buying decisions that preserve optionality. Choose open platforms with public APIs so your data and workflows are never hostages. The most important feature of your next system is your ability to leave it β because in a fast-moving era, lock-in is how you get stranded on a harvested product.
If I were running a healthcare organization on a legacy stack today:
- Audit your vendors' trajectories, not their feature lists. Ownership, R&D signal, release velocity, pricing trend. Sort them into invested vs harvested.
- Name a change leader. Someone senior owns organizational change capability β not as a project, as a competency.
- Run one real migration or pilot this year. Small if necessary. The point is building the muscle while the stakes are manageable, not waiting until the stakes are existential.
- Make optionality a hard requirement. No new contract without data portability and an open API. Ever.
- Model the five-year cost of standing still. Not just subscription fees β the labor, denials, and turnover cost of running first-generation workflows against competitors who aren't.
The technology shift is coming regardless of what any of us think about it. The vendors being harvested will keep insisting everything is fine, right up until the sunset notice. The only variable you control is whether your organization is built to move.
Change management isn't the boring operational footnote to the AI era. It is the single most important thing your organization can prepare β because in a period where the ground moves every year, the ability to move with it is the strategy.
Jason Brumback is the founder and CEO of Navix Health, the AI-native EMR, CRM, and RCM platform built exclusively for behavioral health. He is a licensed clinician and former multi-facility operator. Navix's view of where this all goes is the AI Operating System for behavioral health β and its answer to the harvested-software problem is an open platform you're never trapped in.
β
- #future of healthcare technology
- #change management
- #legacy systems
- #ai in healthcare
- #buy vs build
- #healthcare software strategy