About this episode
Michael Moor is a medical doctor doing his PhD in the Machine Learning and Computational Biology Lab at ETH Zurich. Some of his most interesting research looks at predicting sepsis using machine learning approaches.
In case you're unfamiliar, sepsis is a life-threatening condition in which the body's natural defences against an infection go into overdrive. Mortality from septic shock can be up to 50%, and every minute counts — in fact, for every hour treatment is delayed, mortality increases by 7.6%.
We started off by talking about a paper published in JAMA earlier this year. It assessed a popular sepsis prediction tool and found that it wasn't very good: it was delivering so many false positives that doctors would need to assess up to 109 patients flagged by the tool just to find one who was actually septic.
In this conversation
- The alarm-fatigue trap: a widely deployed sepsis model flagged so many patients that clinicians had to assess up to 109 alerts to catch one real case — and Moor's fix is brutally simple: never fire a second alarm after the first.
- The dirty secret of sepsis-prediction research: around half the literature leans on a single US dataset (MIMIC), so models look great on paper and fall over the moment they meet a new hospital.
- What "cleaning and harmonising" ICU data actually means — mismatched units, different measuring devices, patients supposedly 200 metres tall — and why a single variable can swallow a year of a PhD.
- Why the black box won't fully open: explainability is hypothesis-generating, not proof, and Moor is candid that you can't be certain what a deep model is really keying on.
- The uncomfortable politics of medical data: too many teams guard their dataset like a goldmine, which is why there's almost no ICU data from India, China or Africa — and no way to trust these models there yet.
Transcript AI-generated
In that JAMA paper, published in June 2021 — the external validation of the Epic Sepsis Model — one of the big issues was that it was notifying for far too many patients. It was too sensitive. It would flag up to 100 potential cases just to identify one actual case. So you get notification fatigue: people are getting all these alerts, and there's no way you can examine that many patients for sepsis.
So it becomes a bit useless, and maybe even harmful, in the sense that it's wasting your time.
“Alarm fatigue is one of the biggest challenges when you're trying to develop an early warning system — so it's important to think deeply about it from the very earliest stage of the project.”
Michael
Absolutely, I fully agree. Alarm fatigue is one of the biggest challenges when you're trying to develop an early warning system, so it's important to think deeply about it from the very earliest stage of the project — because having a retrospective dataset and playing around with it is a very different thing from actually deploying it and having to do something meaningful.
Some of the projects I've been involved with try to address alarm fatigue in a rather hacky way: if an alarm is raised, you silence the model so it can't raise another one for maybe eight hours. A slightly more principled version we've been working on is to say that, across the entire evaluation of the model, you never raise another alarm after you've raised one. That sounds hacky too, of course, but at least it means you can never call more than one false positive per patient.
So if a patient will never develop sepsis and the model has already raised an alarm, it can't raise one again. Now, you might say — well, the sepsis might happen two days later, and that would be a problem. But every strategy has its ups and downs. Alarm fatigue is a big challenge, and it's not easy to address.
Another thing I read from your preprint was that, in general, something like 50% of the sepsis-prediction literature uses one dataset — the MIMIC dataset, a US dataset of, I believe, ICU patients. That sounds like a problem as well.
Absolutely — although it depends a bit on who you ask. In the systematic review we wrote, I think we arrived at roughly 50%. Another review on sepsis prediction found an even larger number, maybe 60%. So the ballpark is around 50-ish. It just shows that MIMIC is, compared to other datasets, of really high quality — and really easily accessible.
That has a big advantage: many, many research projects have been made possible only because of this dataset, which is amazing. But it also has a downside — so many papers are based on this one dataset. Other datasets exist, but many of them aren't available, so it's really hard to externally validate a new model on anything else. You need a connection to those hospitals or centres, and if you start with a raw dataset it might take another year or two to get everything together — to map all the variables, to implement the sepsis label, which is a huge effort in itself. So external validation will always be a problem in sepsis prediction, because harmonising and mapping a new dataset into your pipeline is such a huge effort.
That's what motivated us to say: let's take all the big public ICU datasets — there were four or five, depending on how you count — and pull all of that data together, harmonise it, and map all the variables as best we could. Then we created one sepsis implementation, so we could train models on one dataset, evaluate on the next, and play around in all those directions. It took us several years, and the work is now under review, but once it's out I think it could really help the field — it'll make it drastically easier to externally validate your model.
So you noticed that more than half the research in this field uses just this one dataset. You clean it, filter it, harmonise it, put it all together, and release it to the world. Can you talk through that process? What do cleaning, filtering and harmonising actually mean, and how difficult is it — for someone who doesn't understand any of it?
Good question. There are always several layers of filtering and cleaning. If you start right at the collection stage — which is what we also do in Switzerland, in a different project — then you're much deeper into the woods: you have different centres, it gets very difficult, and you need expertise from very different fields all in one place.
But in this situation we had the chance to work with already-published databases that have been curated to some degree. MIMIC is highly curated; the eICU dataset too. I want to be clear that we're walking on the shoulders of giants here — other people already thought about anonymisation and making sure there are no big errors in the data. There are always some remaining errors and artefacts, of course, but we started from a good place.
The first thing, when you try to include a new dataset, is that you always need to know what is what. If we want to use pulse-oximetry measurements from one dataset, how do they relate to the measurements in another? Is the distribution similar? Is there some bias? Is the mean just higher — and if so, is that due to a different population, or a different device doing the measuring?
You have to ask this for almost every variable, and it might be 50 variables, 100, or 2,000, depending on how far down the rabbit hole you want to go. Take blood pressure: what devices were used? Is there a systematic difference between them, and is that difference harmful or even useful? Usually it's harmful if the differences are drastic. Then there are units — especially moving between European and American datasets, you get different units for things like temperature, and you have to map them accordingly. And there are outliers: measurements where you're quite sure someone isn't 200 metres tall or doesn't weigh 500 grams.
Often you don't have a recipe to find all the issues top-down. It's really a bottom-up task, in my opinion — you sort it out as you go, and it takes an enormous amount of time.
So when you've got five different datasets and you start noticing bigger trends or issues — say a lot of the patients are very elderly, or belong to a certain race or gender, or their blood pressure runs much higher — how do you deal with that? Do you just drop those values out of the pooled dataset, or are there other methods?
This is a very difficult question, because ideally you'd find methods other than just dropping data out. But it can be treated as a very deep statistical problem — you could spend an entire PhD on this one thing. It's very nested: at each leaf of the tree you have to decide, will I spend a year on this or not?
If you're not a hundred people, or a huge company with essentially endless resources — if you're a small team of researchers — you have to think really carefully about whether to spend a year on any given problem. In that spirit, we sometimes had to crop away certain patients, or drop certain centres. In the eICU datasets, for instance, some hospital centres don't report many of the variables we cared about, so the sepsis prevalence looked extremely low there — simply because we didn't have the data required to meet the criteria. We had to threshold those out and say, some hospitals have to be dropped, because they'd probably carry a lot of false-negative sepsis patients. That's nasty, of course, because you introduce selection bias. It's good to think hard about these things, but it's also very easy to spend a lot of time on them — and in the end you have to bite some bullets. There's no free lunch.
Generally speaking, I imagine some of your datasets have great data — hourly observations, vital signs — while another has a lot more missing data, maybe four-hourly. When you harmonise everything, do you always have to cater to the lowest common denominator? Or are there other ways to deal with those discrepancies?
Again, a really interesting problem you could easily spend years on. In an earlier paper — with some co-authors of this preprint and other collaborators — we built an early-warning system for circulatory failure, published in Nature Medicine last year. We found that if you train on a high-resolution dataset — five-minute intervals — and then try to externally validate on a lower-resolution one, like MIMIC, it doesn't work as nicely as if you'd trained on the high-resolution data but only used the resolution MIMIC has, which is roughly hourly for many variables.
So I thought it'd be a smart first step to just take the common denominator of one-hour measurements. For internally boosting performance within a high-resolution dataset, higher resolution will be beneficial — but in this preprint we said we'll stick to hourly resolution to get things going, because otherwise you have this combinatorial grid of things to test. We know it can work better with higher resolution for certain variables, but we start everyone at one-hourly, so we have common ground.
Once you have a model and you can see it's performing well, what's the process of working out how it made those decisions — extracting knowledge and learnings that clinicians can use in their own practice? Is that easy to do, or quite challenging?
“In many cases we start with a black box, and it's really hard to open it in a way where you can be certain you understand what's going on.”
Michael
It's relevant, but challenging. In the very early days, the typical way to extract information was some kind of feature ranking or feature selection — and you can still do it: if you train a logistic regression, you can see which features have the highest relevance from the magnitude of the parameters. Nowadays, with deep learning, people rely more on explainability methods. In imaging it's really interesting to see where the model is looking on a CT image; with time series it's a bit different, but you can still work on explainability.
It's hard to take a very solid takeaway from it, though. It's more hypothesis-generating — I don't think you can prove anything with it. For me it's usually not solid evidence, it's more speculative: "ah, interesting, when the systolic blood pressure goes down the model thinks maybe this is a haemodynamically unstable patient, and raises its prediction score." Explanations are interesting, but I'm always very careful with them, because there's so much going on at the same time. It's a big wish to have explainable predictions, but in many cases we start with a black box, and it's really hard to open it in a way where you can be certain you understand what's going on. Getting the black box out completely is really hard.
If we think about the future of ML and sepsis prediction — can you see, in the near future, a situation where these tools become so good that a patient developing sepsis in hospital becomes a never event? In the sense that it should just never happen, because the tools are so good at picking it out — and if it does happen, that's a big failure by the hospital team. Do you see us getting to that level?
That would be amazing. My ML self would say, yes, of course. My medical self would say, well, this isn't really possible — because in many cases sepsis starts before the patient even enters the hospital, or while they're in the emergency department. We only work with ICU data, because it's the highest-resolution and most available data. But if you really want to solve sepsis, you might need mobile tracking of patients — so it could take more than a few years to get to that point.
And to be honest, even if you identified sepsis extremely early, I'm not sure what percentage of "breakthrough" sepsis there would be — that still has to be studied. But I'm certain it'll get better. The big problem is this health crisis of sepsis death and morbidity, which is just enormous, and we need to reduce it. Whether we get so far that it counts as a failure when a case appears — maybe that's the music of the future. I don't know.
Are there any exciting preprints or developments happening in sepsis prediction? What's coming over the next few years?
One thing I've seen in several recent papers: people are interested in subtyping sepsis — performing clustering on various kinds of multimodal data, whether time series or molecular properties. I hope there'll be interesting advances in understanding how sepsis can be subtyped into groups of patients that behave very similarly and might respond to particular treatments. That could lead to more personalised sepsis management.
Otherwise, we need to get over the crisis of poor external validation. We need models that can adapt to a new distribution — which is a fundamentally difficult problem in ML for health. Some say ML is essentially all about fitting a distribution: if you want to predict a class given data, you're fitting a conditional distribution. And when the distribution shifts — a new cohort with different ethnicities, different policies among the doctors, different devices measuring and reporting values slightly differently — your model needs to see that and adapt.
That's a big challenge, but it also offers real opportunities for method development. If you approach it from the ML side, you might think you're either doing theoretical ML or applied ML — but actually, applied ML is where you really see where current models fall short, and what needs to be done next. Method development, in my opinion, should be inspired by the problems we encounter in practical applications.
Another potential issue, going back to the datasets: I don't know of any public, easily accessible, robust datasets for sepsis or ICU patients from less economically developed countries. The ones I've come across are all US, Swiss, Netherlands. Why is that so hard? Is it that the data isn't being recorded in their ICUs, or is it the ethics and bureaucracy? I appreciate you're not an expert on this specifically, but what are your thoughts?
“The big collaborative effort is sometimes missing. Too many studies work like — we build a goldmine, and once we have it we mine as much as possible, and make sure no one else can benefit.”
Michael
As you say, I'm definitely not an expert, and I couldn't tell you the exact problem in any individual place. But there's a problem rooted much more deeply in the medical profession. Wherever you go, you have a hospital collecting data — and a big reason it's so hard to make that data available is that the clinicians and study directors often feel the data belongs to them. It's their goldmine, to be protected from intruders who might steal insights from it.
I think this is prevalent everywhere: the big collaborative effort is sometimes missing. Too many studies work like — we build a goldmine, and once we have it we mine as much as possible, and make sure no one else can benefit except through the study we eventually publish in the New England Journal. You know what I mean? So getting access to patient data is a slow, bureaucratic process, with many players and stakeholders who have no interest in making it public. That's one problem — though it's not necessarily why we see such a bias in the datasets that are available. I honestly don't know the key reasons for that bias, but in the preprint we did say we need a more inclusive, more global representation of patients. Otherwise we'll never have the validity to deploy models in countries that differ from the cohorts we trained on.
If you were keen to get data from a country that doesn't already have these public datasets — pick anywhere, say India or China — how difficult is that process? How big a task is it to find some ICUs, collect the data, get the permissions, and get it into your dataset?
If there's no research database already, and you have to collect it from the reports and databases yourself, it's a huge effort — you usually need a big team spending months or more. Even for the one Dutch dataset we use in our study — which is quite clean and readily available in a nice relational format, almost the end of the story — there were still bridges and translations needed, because some terms were in Dutch and you have to translate them and make sure they mean the same thing you're talking about. So going to India, or anywhere else, to integrate their ICU data would be a huge effort. And there aren't enough incentives to do it right now — that's a big problem too. My dream is that in 10 or 20 years we'll have ICU datasets gathering data from all over the globe, with African and Asian countries included. But it'll be a long and painful road until we get there.
Throughout your career, have there been any habits or ways of approaching things that have been especially helpful for you?
Yes. One slightly weird habit during my studies was to really follow my curiosity — even when it had absolutely nothing to do with what I needed to know at that moment. During my bachelor's, even though I was studying medicine, in my private time I very often read about mathematics in some really cool books. Friends would ask, why are you doing this? It doesn't help you in any way. But for me it was inspiring, and it widened my horizons — and later it was really helpful, because it made it much easier to get onto the machine-learning track.
So I think it's extremely important to keep learning, especially in the medical profession. If you're interested in the digital and technological side — early-warning systems, ML applications — extend your curriculum, take initiative, and learn things that aren't necessarily meant for your ears. There are many good books out there, and good podcasts too — this one's a good first start.
If I could start medical studies again, I'd try to be open-minded and follow up on interesting topics that aren't typical for medicine — more technical, more mathematical — and branch out. Because during medical studies I often felt almost forced through a pipe, like a worm being pushed through it: you need to know this, and you're afraid of forgetting the important things that might cost a patient's life. But that's not what studying should be about, in my opinion. You should also be able to be curious, and explore.
I hope you enjoyed that episode. If you've been enjoying the podcast, please consider leaving a review — thank you.