Why healthcare AI projects (and not only) often fail to deliver real value

Healthcare organisations don’t fail because they chose the wrong model, technology, or implementation. The root cause usually lies deeper than that. Often, these initiatives fail because the project was not set up to deliver meaningful value from the start. Even the most promising life sciences prototypes may fail right after the demo - I’ve seen it firsthand in many projects.

It’s not only a healthcare problem, but it’s definitely more visible there. Across industries, organisations are investing in different technologies, including AI, without answering key questions about the main problem to solve, data foundations, or what the reality looks like. In such cases, the result is often a shiny project that proves what particular technology can do, rather than what’s needed.

I have seen the same underlying problem across complex software projects for years, but AI makes it even easier to see. We can move from ideation to implementation and development faster than ever. And because of that, the decision about what to build and what to dismiss becomes more important than ever.

Does it connect with the reality of clinical workflows?

The idea might be strong and seemingly valuable, so the decision is to build. But once the product enters a real clinical environment, what is supposed to support clinicians in their daily operations might actually turn out to be the opposite. If the solution doesn’t fit the way clinicians work in reality, it can add more complexity instead of removing one. For example, if they need to enter the information twice or switch between systems simply to use the tool, that’s how adoption drops.

And that’s why this matters. Before introducing an idea and moving to development, retrace the existing workflows and understand where the friction sits, and whether the solution will remove or simplify existing steps or whether it will add new ones. While building a prototype, discuss and test the solution with people for whom you’re building it. They can point to where the value is and where potential flaws might occur.

Actually, while designing an assessment tool for postnatal care, our team interviewed midwives, nurses, and physicians and analysed the workflows to design a product that would fit more naturally into their reality and simplify their work.

The lesson is straightforward: a solution should be tested not only for whether it works, but for whether it works within the workflow it’s meant to support.

Is your data foundation ready to support it?

This is the problem that became particularly apparent for AI implementation. In many cases, the data is scattered across multiple systems, EHRs, locked in incompatible formats, or inconsistently structured. Often, it’s unclear who owns particular datasets, how they should be governed, or whether they can be used in the first place.

That creates a gap between what an AI solution is designed to do and what the organisation can reliably provide it with. In a controlled environment, everything may work fine, but what happens in the real workflows with real data - that can be difficult to assess.

That’s why I often repeat that data foundation is everything. Look beyond data volume or availability. Focus on access, quality, interoperability, and how data moves through the workflows the AI is meant to support.

Do legacy systems stand in the way?

Leaders can’t ignore the existing systems that already run the organisation. In healthcare, especially mature systems, implementing a new solution usually means connecting it with a legacy clinical system or EHR or any other infrastructure that was never designed to support modern solutions, like AI.

It’s not just about whether these two systems can technically be connected - there often is a way to do it. But it might require additional development, data transformation, testing, security controls, and ongoing maintenance. So, what looks like a relatively straightforward implementation can become a much larger project adding time, cost, and operational risk.

If integration requirements are treated as an afterthought, healthcare organisations can end up investing in a solution that works in isolation but is difficult, costly, or disruptive to use in the environment where it actually needs to deliver value.

Is compliance built-in from the start?

Compliance is probably one of the critical factors in healthcare. These requirements shape how the software solution should be designed right from the start, including things like data handling, security, or auditability. Yet, too many times I’ve seen these being treated as an afterthought, something teams can address later once the final product is almost in place.

Retrofitting to the GDPR or HIPAA requirements mostly means rework. Teams need to check large parts of the system and rewrite where necessary to comply with compliance standards. In turn, development time stretches, costs increase, and launch is pushed away.

Not to mention the costs that come with compliance failure. That was the problem we’ve seen in the clinical trial project. The University of Birmingham ran clinical research supported by the external software vendor, and even though everything seemed to be on track, something didn’t feel right. Through our assessment, we’ve found critical issues that could impact compliance and participants’ data anonymisation. Our experts advised steps to ensure HIPAA compliance and data protection.

Leaving compliance until later is never a good call nor a shortcut. That’s why leaders should always treat it as an integral part of development – one that has a huge impact on how the system should be developed, how data should be handled, and what security measures should be in place.

What’s the real measure of healthcare project success

In a healthcare software project, whether it delivers value doesn’t come down to just whether it works. There are many factors that need to be considered before the development starts. Examining the real workflows, data foundations, existing systems, and compliance with regulatory standards – all need to be a part of the project development.

So, don’t ask how fast the team can build it. Ask whether it can work here, for these users, within the constraints, and still deliver a measurable outcome.