Is your data team solving the wrong problem?

I ran a data team of thirty-five people at Oxleas NHS Foundation Trust. After a few years in the role, I found myself asking a question that I suspect most heads of data eventually arrive at: what is the point of what we are doing here?

We were producing executive reports. Commissioner reports. Board reports. CQC preparation packs. Statutory returns. The machinery of it consumed almost all of our capacity. But when I sat in the meetings where these reports were received, the data was brushed over in minutes. Commissioners would flick past the activity numbers and spend the meeting talking about specific incidents, specific complaints, specific CQC findings. The qualitative material, the stories and the details, carried far more weight than anything my team had produced from a warehouse.

I started looking at what happened after those meetings. The answer, overwhelmingly, was nothing. The minutes would show "noted" against item after item. Occasionally someone would ask a clarifying question, which would generate a further piece of analysis at the next meeting, which would also be noted. The cycle of production and consumption was largely self-referencing. Data went up, got acknowledged, and came back down as a request for more data.

Thirty-five people, working flat out, and the most common outcome of their work was a line in a set of minutes that said "noted."

The quality problem underneath

The deeper issue was that even if those reports had prompted action, the numbers themselves were unreliable. There was no master data for teams and staff. There were no formally defined data items. There was no stewardship model in which the people who owned clinical processes also owned the data those processes produced. The basics of data management, the DAMA principles that every other industry takes as a starting point, were almost entirely absent.

Yet the view from the boardroom was bullish. The Trust had invested heavily in its reporting platform, iFox, and in the RiO electronic patient record and they were proud of that, and happy to dig into their finite financial reserves to do so. The tools existed, but the investment had gone into extraction, transformation, and presentation of data. Almost nothing had gone into the foundational layer: agreeing what the data means, who is responsible for it, and what standard of quality is acceptable. Instead, the conversations were retrospective discussions about how to define a metric for the exec or for the regulator, with no clinician in the room. Without that layer, every report was built on sand. Commissioner meetings were reviewing figures that could shift by double digits depending on which analyst had run them and which assumptions they had applied.

I eventually wrote a Data Governance Framework for the Trust, signed off by the Information Governance Committee in 2021, that attempted to address this. Its opening line stated the objective plainly: "Clinical teams will get the best possible value from the data we collect and we will drive down the effort of data collection, correction, and management." The fact that this was a novel statement of intent tells you something about how data teams in the NHS have understood their purpose.

Turning to the frontline

I changed tack. Instead of working through business managers and directors, who invariably treated data as someone else's problem to delegate downward, I went looking for the people who actually ran the clinical processes. The operational leads. The team leaders. The people everyone went to when they had a question about a patient or a decision to make.

I found one in CAMHS and one in the adult learning disability service. There were others, but those two stood out. For both of them, the experience of being able to talk directly to someone in data was something close to a revelation. They had always been blocked by the system. They would ask for something and be told by their business manager that the data team was too busy, or that it was not possible, or that they needed to fill in a request form. The gatekeeping was institutional and, in most cases, well-intentioned. But it meant the people with the most to gain from good data had the least access to it, and would build their own low-tech solutions.

I asked them a simple question: what data do you actually use day to day?

The answers had nothing to do with board reports. They were shouting information across the room to each other. They were emailing patient lists back and forth. They had whiteboards covered in handwritten notes taking information gained from phone calls. They were running WhatsApp groups to coordinate who was seeing whom. One team had a paper-based system of coloured sticky notes to track which patients were highest risk. These were the real information systems: informal, unstructured, fragile, and completely invisible to the data warehouse.

Building what the frontline needed

Once I understood what they were actually trying to do, the work changed fundamentally. We stopped asking "what reports do you need?" and started asking "where are your struggles, and how can data help?"

One team was spending hours manually booking appointments through a process that had grown organically over years and no longer made sense. We built them a booking system on our BI stack. It was not glamorous work, but it removed a significant administrative burden and gave them reliable visibility of their clinic schedule for the first time.

Another was losing patients in their pathway. The stages between referral, assessment, treatment, and discharge were tracked across multiple spreadsheets and whiteboards, with no single view of where each patient sat. We mapped their workflow in Lucidchart and put live numbers against each stage, so that for the first time the team could see at a glance where patients were accumulating and where the process was breaking down. The waiting list was no longer just a number at the front door. It was a picture of the whole journey. Not pretty, but it was effective.

The zoning tool was probably the most clinically significant. Zoning is a mechanism used across mental health services in which patients are categorised as red, amber, or green according to the risk they present. It determines contact frequency and the intensity of the care package. At that time the process was manual and laborious. Clinicians came to twice-weekly meetings and talked through their entire caseload. The minutes were captured on a template, typed up into a Word document, and then a receptionist would copy the relevant sections into each patient's clinical record on RiO.

We looked at whether we could draw on structured data already recorded in the electronic patient record to produce an automated risk summary. The idea was that a clinician could open a patient's profile and see an instant visual indicator of their risk classification, with the underlying factors enumerated beneath it. This work eventually became a formal research collaboration with the University of Westminster, published at the 19th International Conference on Informatics, Management, and Technology in Healthcare, proposing a framework that combined temporal abstraction, natural language processing, and supervised machine learning to predict zoning classification from historical patient data.

The point is not the sophistication of the tool. The point is that this work started with a frontline clinician describing how they spend their time in a zoning meeting, and it ended with a product that could give that time back to patient care. The data team was solving a problem that a clinical team actually had.

What the frontline gave back

The returns from this shift were not only operational. The CAMHS and ALD leads became vocal advocates for what data could do. Their credibility was unanswerable because they were speaking from direct experience: this data helps me see my patients, manage my caseload, run my team.

When I brought them into the Information Governance Committee, they found attendance from each corner of the organisation had been delegated down to band 5, and the exec in charge was only there under written instruction to chair it personally. The new governance framework had a dramatic impact. This was a forum that had previously spent its entire agenda on FOI volumes and data breach reports, now talking about what their real information challenges were and how the data team was helping them address those challenges. It was the first time the minutes of a formal board subcommittee reflected the operational value of data rather than only its risks.

That mattered. It meant the work was no longer a side project run by the head of data. It was on the record, in the governance structure, endorsed by frontline clinical leaders. The data ownership concept, borrowed from DAMA and adapted for an NHS mental health context, was gaining institutional traction.

The disconnect that hurts everyone

I left Oxleas before the work was complete. But what I have seen since, across many Trusts, is that the dynamic I found there is almost universal.

I was talking recently to a senior data leader at another mental health Trust who described the same pattern from the other side. He had moved from leading a data team to a role where he was now their internal customer. His observation was blunt: the incentives are completely different. The data team is doing its best, working flat out, under enormous pressure. They are completing ad hoc requests, hitting statutory deadlines, producing the monthly board pack. When they have had a productive day, they feel good about it, but the output of that productive day has almost no connection to what the organisation actually needs from data.

He described trying to engage the team in a piece of analytical work he was doing, trying to be the model customer, and finding that they simply could not have the kind of open-ended, exploratory conversation that good analysis requires. They needed to know what columns he wanted. They needed a specification. They were trained, by years of operating under relentless demand, to take an order, execute it, and move on to the next ticket.

It was there to see in their eyes, he said. The pressure. The defensiveness. The sense that any question about whether the work was adding value was a criticism of people who were already stretched beyond what was sustainable. The absence of any positive feedback, because the work they were doing was by definition invisible to the people it was supposed to serve.

This is the human cost of the misalignment. Data teams in the NHS are staffed by skilled, committed people who are working extremely hard on things that generate almost no operational value, receiving almost no recognition for it, and having no time to step back and ask whether there might be a better way. When someone tries to raise that question, the response is defensive, because the team is already at breaking point and the question feels like an attack.

I have seen data teams burn out and collapse under this pressure. I watched it happen at another Trust where I led the data function, where the team became so fractious. The dynamic is corrosive, and it is almost entirely a product of how the team's objectives have been set.

The problem does not stop at Trust boundaries. NHS England runs a burden reduction programme that has been trying for years to reduce the volume of data collections imposed on Trusts. In three and a half years at NHS England I did not see it reduce a single collection. The reason is structural. Roughly a thousand analysts at the centre depend on national data submissions to do their work, and the policy teams who commission that work have their own settled view of what the data means and what it is for.

The local perspective, from the Trusts that actually collect and submit the data, is almost entirely absent from that conversation. Trusts do not understand how their submissions are used downstream. Policy teams do not understand how poor the data quality is at source, or how little local ownership exists over the figures being submitted. The analysts in between are confident that someone upstream is directing them well, and someone downstream is recording the data carefully, and neither assumption is reliably true.

There are some exceptional analytical leaders at NHS England, people who see this clearly and have tried to fix it, but they do not have enough organisational authority to redirect a machine of that scale. So the cycle continues: Trusts submit data they have limited confidence in, the centre analyses it as though it were reliable, and the burden reduction programme tries to remove collections that the policy teams will not release because their own work depends on them.

What Trusts should do about it

If you are a Trust chair, a chief executive, a medical director, or a chief operating officer, ask yourself a question: do you know what your data team is doing? Not in the abstract sense of "they produce our reports." In the specific sense of: what did they spend last week on, and what changed as a result?

If the honest answer is that the team spent most of its time producing statutory returns, commissioner reports, and board packs, and that the most common outcome of that work was that someone noted it in a set of minutes, then you have a problem that no amount of additional recruitment or new technology will fix. The opportunity cost of such a situation is incalculable.

The fix is to change the team's objectives. Point them at operational problems. Give them permission to work directly with clinical and operational leaders, the people running the wards, the community teams, the crisis services, on the things those leaders are actually struggling with. You will find, as I did, that the data products which emerge from that work look nothing like traditional BI output. They will be booking systems, workflow visualisations, risk stratification tools, team-level metrics that clinical leads have defined themselves because the numbers reflect how they actually manage their service.

And when clinical teams are getting value from data, a remarkable thing happens to data quality. People record data properly when they can see the point of recording it. The appointment goes into the diary correctly because the booking system depends on it. The risk assessment gets updated because the zoning tool reads from it. The care plan is completed because the team dashboard surfaces it. Data quality becomes a by-product of operational use, not an abstract standard imposed from above that clinicians have no reason to comply with.

The statutory returns, the commissioner reports, the board packs will still need to be produced. But if the data underneath them is accurate because it was collected for operational reasons rather than reporting reasons, those outputs will be reliable for the first time. And they will take a fraction of the effort to produce, because you will no longer need an army of analysts to manually validate and correct data that was entered badly in the first place.

I know this works because I did it, in a large, complex mental health Trust, with no additional budget and no special permission. I just stopped spending time on things that were not generating value and started spending time on things that were. The frontline will tell you what they need if you ask them. Has your data team ever asked?