Context
I joined DeepMind in 2017 as product lead for Streams, a mobile product that put the detection and prediction of acute kidney injury and the interventions that follow, into the hands of the clinicians who could act on it.
A milestone for DeepMind Health and StreamsScaling Streams with Google
What the real problem was
The detection logic was the smallest part of the problem. An alert that arrives at the wrong person, at the wrong time, or without enough context to act on, changes nothing. Three things mattered more than the algorithm.
Trust in the prediction: a clinician who cannot see why an alert fired will either ignore it or over-trust it and both failures are expensive. We designed for the reasoning to be inspectable, explaining the values behind the result, when they were taken, what changed, this made the alert an discovery rather than an instruction.
The workflow, not the notification: most of the product work was about routing, escalation and what belongs on a phone screen at 3am, with alert fatigue as the constraint we designed against throughout.
Safety and regulation as design inputs: hazard analysis, clinical safety cases and information governance shaped the product from the start rather than being cleared at the end.
Beyond kidney injury
AKI was the first use case, not the whole product. Streams grew into a way for doctors and nurses across the hospital, in multiple disciplines, to reach a patient’s results, observations and history on a phone at the bedside, rather than at a desktop terminal on another ward. Early feedback from nurses estimated it saved up to two hours a day.
Extending that access meant treating three things as product work rather than hurdles.
Regulation: Streams was a clinical product, so the regulatory position shaped what it could show, recommend and alert on, and what evidence each change needed.
Clinical safety: every new view and alert went through hazard analysis and the clinical safety case, with clinicians involved in deciding what was safe to put on a phone screen.
Integration and interoperability: the value depended on data arriving from each Trust’s existing systems in a form clinicians could trust, which made integration with hospital systems, and the standards behind it, part of the core product rather than a technical afterthought.
What happened
Deployed across NHS Trusts with more than 10,000 weekly active users. The app and team were later merged into Google Health and the learnings, product work and relationships were extended into Google products launched for health sectors.
What I would do differently
Widening Streams from a single alert into a product for the whole hospital is what made it valuable enough to scale. NHS Trusts and health systems were not buying an algorithm. They wanted predictions and insights that were accurate, clinically meaningful and trustworthy, delivered inside the workflow their teams already used.
In those early days of health AI, the hardest risks were not technical. They were value and usability risks. Clinicians were used to systems that returned a binary yes or no, and a prediction with a confidence level asked them to reason differently. Looking back, I would treat that education as part of the product from the first release, testing how people interpreted confidence and accuracy as early and as deliberately as we tested the model itself.
A note on trust
This was a period when public scrutiny of health data partnerships was intense. That context is part of the story, and it sharpened how carefully the product handled consent, access and transparency.




