A hospital can buy sophisticated software and still make patients repeat the same information three times. It can introduce automated scheduling and still leave staff calling each other to confirm whether a bed is ready. It can deploy a highly accurate predictive model and then discover nobody has the authority to act on its predictions.
Technology is often introduced into healthcare with the expectation that it will remove friction. Sometimes the friction is not a software problem in the first place.
At Web Summit 2026, Portuguese state-reform minister Gonçalo Matias made an argument that should sound familiar to anyone who has watched a hospital IT implementation struggle. Before deploying AI, he said, governments need to simplify their processes and clean the information on which those processes depend. Adding intelligence to a system built around unnecessary steps can merely make those steps happen faster.
He was speaking about government reform broadly, not presenting a detailed study of hospital implementation. The translation to healthcare is ours. But it is a particularly relevant one because hospitals combine time-sensitive work, complex responsibility structures, legacy software and people who cannot safely be treated as interchangeable units.
Follow one patient through the system
Imagine someone referred for a specialist assessment after an abnormal test result. The referral moves from primary care to a hospital. A secretary checks whether the documents are complete. A clinician decides on urgency. A booking team searches for a slot. The patient receives instructions. The specialist eventually discovers another investigation is required, and the process begins again.
There are legitimate reasons for many of those stages. Clinical triage protects patients, consent matters and different teams have different responsibilities. The difficulty lies in the repeated handoffs that add no clinical value. A missing report can generate days of avoidable delay. Conflicting information can trigger duplicate work. A system that flags incomplete referrals only after they enter the specialist queue may be too late to prevent the disruption.
Now imagine introducing AI to generate better booking recommendations. The model might allocate appointment slots extremely well. Yet it cannot repair a referral policy that sends patients to the wrong service or a workflow that fails to obtain required information. It may simply schedule the wrong people more efficiently.
The first design task should therefore be to draw the pathway as it actually operates. Not the idealised process in a presentation, but the lived sequence of phone calls, workarounds, paper forms, spreadsheets, delayed approvals and undocumented decisions.
Only then can the team decide where a model could genuinely help.
The difference between waste and necessary complexity
Simplifying healthcare is not the same as removing clinical safeguards. A second check of a medication order may be essential. A confirmation of patient identity is not pointless bureaucracy. A deliberate escalation route for concerning symptoms is there for a reason.
The challenge is to distinguish steps that protect safety from steps that survive because nobody has redesigned the process. The distinction cannot be made by a software vendor alone. It requires clinicians, nurses, administrators, operations leaders and patients to explain why each action exists.
Take discharge planning. One hospital's delay may be caused by a predictable pattern of bed turnover. Another may face barriers in social care or patient transport. A forecasting tool that addresses the first problem may be irrelevant to the second. Buying the same “AI discharge solution” for both could produce very different results.
This is why implementation should begin with a testable problem statement. “We want AI in discharge” is not a useful brief. “Patients medically ready for discharge spend an extra day waiting because transport arrangements are started too late” is a problem that a team can investigate.
It may turn out that a clearer ownership rule solves the issue. If so, that is a success, even if there is no AI product to purchase.
Data quality is a clinical issue
Matias's remarks also emphasised clean data. In healthcare, this is more than a technical preference. Data may reflect clinical decisions, patient identity, medication history, appointment status and the timing of interventions. An incorrect or outdated field can undermine even a well-designed algorithm.
Hospitals often have several versions of the same truth. A patient's expected discharge date may appear in a ward note but not in the bed-management system. A referral may be marked complete in one application while additional documents are still pending elsewhere. A model trained on such information can learn the habits and inconsistencies of the organisation rather than the underlying patient need.
Before asking whether an algorithm is accurate, teams should ask whether the data represents the decision they intend to improve. How often is it updated? Which staff member has authority to correct it? What happens when two systems disagree? Can a recommendation be traced back to its sources?
The European Health Data Space aims to improve interoperability and cross-border sharing of health information over a phased timetable. That long-running programme illustrates the scale of the problem: useful healthcare AI relies on information architecture that extends far beyond any single algorithm.
Why pilots often look easier than scale
A pilot usually benefits from attention. Senior leaders are interested, the vendor's best team is available, and local staff have the energy to make the project work. Problems are solved by people standing close to the implementation.
The danger comes when the organisation interprets a successful pilot as proof that the product will perform equally well across ten hospitals with different processes and staffing. The model may transfer; the surrounding operating system may not.
A useful pilot should record all the hidden work required to make it succeed. Did staff need to clean records manually? Were exceptional cases routed around the system? Did the vendor adjust rules every week? Was a dedicated project manager solving issues that ordinary departments would have to handle later?
These are not reasons to abandon the technology. They are part of its true cost and implementation requirements. A credible commercial case should include them.
HealthTech founders sometimes treat requests for workflow changes as resistance to innovation. Occasionally they are. Often they are legitimate signs that the proposed solution does not fit the clinical environment. A nurse asking who will review an alert is not being uncooperative. They are identifying the person who might become responsible when something goes wrong.
A better order of operations
The most practical approach starts with observation, not procurement. Map the pathway and quantify delay, errors, rework and patient impact. Separate genuine clinical constraints from avoidable administrative friction. Standardise what can safely be standardised. Clarify responsibility. Improve the quality and availability of data. Only then test which decisions benefit from prediction, generation or autonomous action.
In a real hospital, those steps will overlap. A limited prototype can reveal process flaws that staff never documented. But a team should resist presenting AI as the solution before the underlying problem is understood.
The World Health Organization's guidance for large multimodal models emphasises well-defined tasks, reliability, stakeholder involvement and attention to downstream consequences. Those principles fit neatly with the minister's argument. The right question is not whether a model can perform an impressive function. It is whether that function makes the overall system safer or more useful.
What this means for the market
As AI development becomes cheaper, healthcare organisations will be offered more tools, often with similar promises. Founders who deeply understand a workflow may have a stronger advantage than those who merely offer an attractive interface.
The commercial conversation can become much more concrete. Instead of offering a hospital a general AI platform, a company can show a mapped pathway, baseline costs, intervention points, audit controls and a realistic implementation plan. The buyer can then evaluate the proposed change rather than simply the novelty of the technology.
That approach also respects clinical reality. Hospitals are not technology showrooms. Their success is measured in whether patients receive appropriate care and staff can deliver it reliably.
Matias offered a useful warning from the stage in Lisbon. If the process is broken, adding intelligence may accelerate the failure. For HealthTech, the smarter product often begins with the unglamorous work of understanding why the process exists at all.
Key Signals
Adding AI to a broken process accelerates the breakage: automated scheduling on top of unclear bed ownership just produces faster confusion. The sequence that works is simplify the process, clean the data, then digitise, because a model cannot fix a step that should not exist. For founders, the uncomfortable implication is that the product is often the process redesign, not the algorithm.
