Change management is getting a new test in the AI era, and healthcare teams can’t treat routine software updates the way they used to.
For a long time, healthcare IT teams have lived with a steady flow of vendor software releases. Most organizations already have solid habits around them: read the release notes, run testing, confirm integrations still behave, then push the update into production. It’s been standard work, part of keeping a modern healthcare application stack running for a couple of decades. What’s shifting isn’t the cadence, it’s what shows up inside the update.
When is a Software Update More Than Just a Software Update?
Not long ago, many software releases were familiar; bug fixes, security patches, performance tuning, with a new feature here and there. Now vendors are slipping AI “features” right into the products people use every day. Updates that used to feel straightforward can quietly bring in new behavior: automated recommendations, chat functions meant for staff or patients, predictive analytics, documentation assistance, workflow automation.
Are these new features useful? Possibly, however, they are also easy to underestimate. This doesn’t mean organizations should pump the brakes on innovation. It does mean each release deserves a closer look, and in some cases, the same kind of evaluation you’d give a brand-new tool. Reviews of security controls still apply. So do benefit reviews. And the knock-on effects across the rest of the software you rely on need to be considered, too. The updates that are released today may be more than we are accustomed to receiving.
An increasingly common problem in healthcare is that AI arrives in small steps. Release notes might mention a “workflow enhancement” or an “intelligent recommendation engine” and leave out the practical reality of what changed for the people using the software to do their work. The feature can operate exactly as intended and still reshape day-to-day workflows. Clinicians, schedulers, revenue cycle staff, operations, even patients might interact with the same application differently after an update because the system is now nudging them in new directions.
Examples show how subtle this can be:
- A scheduling tool starts ranking appointment slots instead of simply offering them.
- A patient engagement platform drafts replies to patient messages that don’t match established, approved language.
- A coding application that begins to suggest diagnoses or billing codes, which can affect reimbursement, triggering underpayments, delays, or denials.
- A documentation tool that drafts clinical notes from ambient conversations but isn’t constrained to capture only what’s relevant to the care of the patient.
None of that is automatically “bad.” Some of it can be a real win. The issue is that these changes can bend workflows in ways a traditional technical checklist won’t always catch and may likely create confusion and frustration with end users. This is why existing change management needs to mature and evolve.
Why Existing Change Management Processes Need to Evolve
Most healthcare organizations already have Change Management policies and procedures that have evolved to work within the organization’s expectations. The point isn’t to scrap it and build something brand new. Perhaps a better framing for this article is evolution, not replacement. Historically, the change review asked questions that were mostly technical: Does the application function correctly? Did interfaces break or change? Is the update secure or address documented vulnerabilities? Did approved testers sign off? Those questions still matter. AI just adds a different layer of questions that aren’t purely about “does it work”. New questions might start with the following then flow from there:
- What decisions is the software now influencing?
- Did the underlying clinical or operations decision model change?
- Will users interpret the output differently than before?
- Are new data sources being pulled in?
- Does this introduce new compliance or privacy concerns?
Start by Asking Better Questions
To address the inclusion of AI, the evaluation must include not only whether the software runs, but how it steers the work. This can be accomplished by asking more precise and detailed questions of the vendor. Oversight improves quickly when vendor reviews get more intentional. Technical specs still matter, but they’re not enough on their own. A formal process should prompt questions like:
- What AI capabilities were added or changed in this release?
- Will certain users or roles see different recommendations than they used to?
- Did the model’s data change, and how was the output validated?
- Can the feature be turned off, or enabled only for specific groups?
- What administrator and cybersecurity controls exist for monitoring and oversight?
One question cuts through the noise: “What might our users do differently once this update is installed?” If the honest answer is “nothing,” the review probably stays simple. If the answer touches clinical decisions, patient communication, or automated workflow steps, the update deserves deeper scrutiny.
Stay tuned for Part 2: “Change Management in the Age of AI: Reinforcing the Need to Identify and Manage Risk” where we will discuss why taking a risk-based approach is correct, but involving the right teams is essential.