Summary
Is integrated patient experience intelligence finally possible in the NHS? Or will infrastructure without design leave us with expensive technology and limited value?
The jigsaw pieces needed for integrated patient experience intelligence are finally starting to come together across the NHS, but the question is whether anyone is going to bother assembling them. In part one of a three-part series, Ben Kenyon examined the fragmentation of the current system. In this blog, Ben explores the infrastructure pieces now forming. But forming isn't the same as working. Here's what's actually available, what it could enable and what still needs to be designed.
Content
Integration isn't a single solution. It's an architecture with three distinct layers that need to work together coherently. Each layer is developing. None is production-ready for integrated patient experience intelligence without deliberate design work.
Layer 1: The Federated Data Platform foundation
The NHS Federated Data Platform (FDP) is already operational across many trusts. Its architecture is designed for exactly this problem: bringing together data sources with different governance requirements and privacy controls while enabling cross-source analysis that is impossible in separate systems.
What FDP could enable: complaints data sitting alongside surveys alongside Friends and Family Test (FFT), each maintaining statutory requirements and privacy controls, while allowing patient-level linkage rather than organisation-level aggregates. Instead of monthly numbers, you connect individual feedback touchpoints to individual patient journeys, with appropriate consent and anonymisation. From there, record-level linking between feedback and clinical outcomes becomes architecturally feasible.
What FDP access doesn't do is structure your data for integration. That requires conscious architectural decisions about how feedback records connect to patient identifiers, how databases that don't currently communicate get linked technically and how cross-organisational data sharing is governed. FDP is a platform that could support integration. It is not integration.
Layer 2: The NHS App as a collection interface
Current feedback collection is fragmented partly because the interfaces are fragmented. FFT implementation varies by trust: different vendors, different touchpoints, different patient experiences. The NHS App offers something genuinely different: established national patient-facing infrastructure, with patients knowing exactly where and how to provide feedback regardless of which service they've used.
The larger opportunity is closing the feedback loop. When Mrs Smith can see that her discharge concerns, combined with similar feedback from others, led to changes in Ward 4B's medication process, she knows her voice was heard. Closed-loop feedback is standard in commercial customer experience platforms. In the NHS, it's rare to the point of being novel. The effect on response rates and data quality when patients believe feedback makes a difference would be significant.
However, this requires design decisions: what feedback to collect, when to trigger it based on care events in patient records and how to surface outcomes back to patients at a service level. The technology can support all of this. None of it happens automatically.
Layer 3: Natural language processing as an analytical engine
Here's the analytical problem integration creates. You now have thousands of unstructured text records: complaint narratives, survey free-text, FFT comments, Patient Advice and Liaison Service (PALS) contact notes, all being coded by different teams using different methodologies. When the same patient describes the same discharge medication failure across three channels, it gets categorised three completely different ways. Cross-source pattern recognition is impossible before you've even started.
Large language models (LLMs) solve this by applying consistent theme extraction across every source. The same taxonomy, the same methodology, regardless of which channel the feedback came through. "Discharge medication counselling failure" gets identified the same way whether it appears in a complaint, an FFT comment or a PALS note. The system can then count properly: 47 distinct feedback touchpoints this month describing this specific issue, across four different sources.
Scale matters here. Manually analysing 100s of complaint narratives per month alongside hundreds of FFT comments and survey free-text responses simply isn't feasible with human capacity. LLM analysis processes this volume consistently and quickly, without the quality degradation that comes from time pressure on manual coders. But applying it effectively requires design choices: what themes to extract, how to structure taxonomies, how to validate consistency. Having LLM capability available is the starting point, not the destination.
In Part 3, I will examine what becomes possible when these three layers connect and what it actually takes to get there.
Other blogs in the series:
About the author
Ben Kenyon has spent around 20 years working on healthcare's harder problems with data, analytics and, more recently, AI. He began on the NHS Graduate Informatics Training Scheme and went on to lead the Business Intelligence function at Manchester University NHS Foundation Trust, the UK's largest hospital trust, before moving into consultancy and health technology.
During his time at Quantium Health, he led the team responsible for taking Quail from concept through to commercialisation and deployment across the NHS. Quail became the first third-party product to go live on the NHS Federated Data Platform and one of the earliest production applications of large language models to unstructured NHS patient feedback—work cited in the NHS 10 Year Health Plan and recognised with an HSJ Award.
His interest lies in the design decisions that turn healthcare data into meaningful intelligence, and, ultimately, intelligence into better decisions and outcomes for patients.
Recommended Comments
Create an account or sign in to comment