AI in Paediatrics and Pathology

A couple of things. I should fess up front — I've always been quite nerdy and into computers. Right from starting medical school I was into tinkering and building computers, and a lot of my research, although it's been in other clinical areas, has been quite data-heavy. Back in the 90s I was doing some work with something called the St Mary's Maternity Information System — a really old DOS-based system, one of the first in the country where you could collect information about deliveries. To run analyses on it, I'd have to come in in the evening, set up some scripts, run them overnight, come back the next morning and get a printout to see what they'd done. And I'd get "error, line three" or something, so I'd have to change the script and wait until the next evening. So I've always been interested in the space. About five years ago here, we started looking at all of our IT infrastructure and its capabilities, and they wanted someone involved in how we maximise the use of data for research. It fitted perfectly with my interests, and that's how I got into the role of Chief Research Information Officer.

A couple of things. As I mentioned, I don't think there are many things that are very specific to paediatrics, but in children's health there are some opportunities that are different. One is uptake of the tech. The average age of our patients is about five, and their parents are in their 20s. So if you want to do something with robots or apps or whatever, our patients will just use them — they're happy to. Doing that in an elderly-care population is very different. So there are some advantages for paediatrics.

But in general there are a few big chunks that go across the whole spectrum. One chunk is: how do you use AI, analytics and data to make better decisions about the hospital? That's been the holy grail of this space for a long time, and no one's cracked it. Take another industry — airlines. They get huge amounts of data from every flight, from every single thing that happens in the engines, and they can analyse it afterwards. They can have a digital twin of the engine and ask, "what if we made this valve slightly bigger?" In theory you could do the same for a health system or a hospital: what if we had an extra CT scanner? What would the impact be? The waiting time for CT would go down — but would you then just have patients who've had their CT stacking up waiting for a blood test instead? The difficulty in healthcare right now is that we're not capturing information in the right digital format to be able to do that. That's one big chunk, and it's something we can learn from other industries.

But more specific to healthcare, there are two big areas. One is clinical decision support: how do you develop a tool that helps you, as a doctor, make a better decision about how to manage an individual patient? That could be an alert; it could be software that reads millions of published articles and summarises them for you. And the third group is what I'd call patient decision support: how do you use apps and other digital tools to help patients manage their own care and nudge them to do the right thing? Those are the three big chunks that sit across everything, and each splits into lots of other areas.

The huge thing that's going to have an impact — and I think it'll be seen much more in specialist hospitals than in primary or general care to start with — is this. At the moment, patients have to physically come to see us just to see a doctor. That's complete madness. Someone has to look after their other children; the whole family has to come down. When a child comes to hospital you have to have people with them. It's a really inefficient way of doing things. It also means specialist hospitals like GOSH are limited in how many patients they can see with a given condition, because there's a physical constraint around travel.

So one of the first things that will happen is — for want of a better word, and it's been used in other industries — democratisation of specialist care. If you can see people by virtual consultation, you can do things much quicker. There's no reason why, if I need to look into your ear, and you had an otoscope with a digital camera on the end, I shouldn't be able to see that in 4K on my screen. That's equally good, if not better, than me peering into your ear myself — and I can capture and record it, so you can build clever things on top. So one big change will be around how care is delivered: remote consultation.

The other massive thing that's going to change everything quickly is data from sensors — home monitoring post-operatively, activity data, ECG monitoring, all sorts. That will have a huge impact across all of medicine, but it raises lots of questions. Where will that data go? What are the standards for it? How do you authenticate it? Is it okay to make a decision on data when you're not sure it's actually from the patient it's supposed to be from? And from a doctor's perspective — whose job is this? Suddenly all this data is coming into the hospital and someone has to make a decision. Everyone flippantly says, "oh, we'll have an algorithm make the decision." Fine — but then whose job is it to make sure the algorithm is doing what it should be doing? So those are the two really tangible things that'll change in the next 10 years.

I think we're at early days yet. But at the same time, personally, I think it would be a disaster if I retire before I'm made redundant. Because the whole point of everything we're trying to do in medicine is to make it better. If you can have a system that performs better at a specific task, you'd be mad not to want it. Think about what we actually do: you take some humans, show them lots of pictures — pictures of tissue under a microscope — and over many years you keep showing them pictures and asking, "do you recognise what this is?" until they can say, "yes, I know what this is now." That can't be the optimal system. Deep-learning systems, AI for pattern recognition — we know they're better than humans in general. So absolutely, we will replace diagnostic radiologists and diagnostic pathologists for many, many tasks, because the systems will be better.

And it's not only that they'll be better — you also remove the limit; you democratise things. Instead of certain cases of breast cancer being looked at by the top two breast-cancer pathologists in the world, because they can't possibly look at all of them, if you have a system that can do what they do, then everyone in the world can have that level of expertise. Same for radiology, and the same for lots of other bits of medicine. Take heart sounds and ECGs. It's completely bonkers that we teach medical students what a heart sound sounds like and have them listen with a pipe, when Shazam can do it for songs. Why can't we do that? Well, we could — if everyone were actually recording heart sounds and annotating them. So it will absolutely change.

What's likely to happen is not that you won't have radiologists or pathologists, but that their role will massively change. And the role of lots of doctors will massively change. People recognise that radiologists and pathologists are probably the first who'll see it. But if you're a cardiologist or a neurologist and you think it won't affect you, you're mad — it's going to change for everyone, just in different ways. For a pathologist, the task of looking at a slide, screening it and making a diagnosis for specific conditions could be taken over by something else. And the first way that happens probably won't be diagnosis — it'll be, say, "we know this is prostate cancer," and then there's a fairly dreary process the pathologist goes through of grading and scoring it, counting all the various things. You can get a system to automate those tasks. So lots of tasks get taken out and done separately.

The question then is: what tasks remain? For a pathologist, the clinical-pathological interpretation still remains, because just knowing what's on the image doesn't tell you the context of the patient. To be fair, that'll probably change over time too, but for the moment it remains. And at a very practical level, if someone has a tumour resected, that tumour still needs to be dissected, the blocks still need to be taken — it's the equivalent of a surgeon; those things will take much longer to change. So the real question, if I were a medical student now, isn't whether doctors will be replaced. It's: will medicine be practised the way it is now in 20 or 30 years? Unequivocally, no. So the question is, in whatever specialty you're going into, what tasks are you not likely to be doing in the future — and if someone removes all those tasks from you, where do you add value? That's what's going to change.

I think we're going in the right direction. Take the concept that, using various deep-learning methods, you can teach computer systems to recognise things in images. It doesn't matter whether it's medicine or not — that's irrelevant. And where the image comes from starts to become less relevant too. It could be a digital photograph you've taken of a wound; it could be for facial dysmorphology; it could be all sorts of things we do visually in medicine.

The easiest place to start has been imaging, because imaging is already fully digitised. And imaging is relatively easy because it's generally greyscale, so the files aren't enormous, and most types of imaging have orientation. A chest X-ray has left, right, up, down — up is always up — which makes it relatively simple to teach a system. One of the first problems you hit with pathology is that in lots of circumstances you don't have that orientation, so there's a question of what tissue you're actually looking at. For a human, if there's a lump of blood clot on the slide next to a biopsy, you don't even consciously think about it — you just ignore the clot. But a computer system has to learn that on this slide, labelled as cancer, that thing is completely irrelevant.

So there's a large part of the teaching process where we're stuck at the moment, because the slides need annotating. Most systems that work well work because you have some kind of — usually initially supervised — learning: you annotate loads of slides and give them to the system, and the system goes, "ah, now I know what epithelium looks like, now I know this bit is cancer," and it learns to extract features. If you just give it a slide, it's much, much harder. So the problems are: firstly, pathology isn't fully digitised in most hospitals. Secondly, when it is digitised, it's full colour, and because of the magnification the file size is huge — a whole-slide image is gigabytes, compared to kilobytes for a radiology image. And thirdly, you need annotation. And who's going to do that annotation? You'd be saying to pathologists, "we'd like you to spend the next five years annotating all these slides so we can put you out of a job." That's a hard sell.

So the first thing for all of these technologies is: until we start capturing data routinely, in an annotated and digitised way, the rest will never be scalable.

Absolutely. It's a problem with how medicine is practised. If you're still capturing things on paper, you can't do anything with it. Even if you're capturing things as free text, that's not ideal. If you're still listening to heart sounds with an analogue pipe, and nobody in the world apart from you can hear what you've heard, then you can't use it for anything. That's the single biggest problem. We're really early in the journey — we haven't even got to the point of saying, "let's digitise everything, and let's standardise the way we digitise everything."

What we realised quite early on, when we were setting up the DRIVE unit, was that a couple of things need to happen to make this work. The first is all the stuff we've discussed — the hospital has to sort itself out and get its own data in order. But once you have your data and you want some cognitive service — say a computer-vision service — the big tech companies have spent billions building those. There's no point in the NHS trying to build its own. You're going to have to leverage and partner on the things coming from the tech industry. So we were really interested in how we could build an infrastructure that keeps your data secure but lets you, for example, pull a cognitive service down onto that data. We scoped around, spoke to various people, and we now have a couple of projects ongoing with Microsoft — some around their cognitive services, some around analytics, a range of things.

In addition to that, one interesting thing — just as a proof of principle — was that we wanted to say: if we're going to link up with these companies, can we think a bit differently, slightly outside our comfort zone? One of the earliest examples with Microsoft was Minecraft. Microsoft bought Mojang, who own Minecraft, and they now have a team of people whose only job all day is building things in Minecraft — professional Minecraft developers. One of the issues we have, because our patients come from all over the country rather than locally, is the worry a child feels about coming to Great Ormond Street. So Microsoft came and looked around the hospital, we gave them the plans, they took photos, and they built a replica — a room-by-room replica of the entire hospital in Minecraft. That means patients can potentially log on and go and see their ward, look around the hospital, go into the operating theatres and the chief executive's office — all the places they can't go in real life. It's one example of something you think isn't really healthcare, but actually it is: if we're going to leverage technology and get people to buy into the potential benefits, we have to stop thinking so rigidly about what is and isn't "healthcare."

It is — they came and measured it. It's not quite brick-for-brick, because the walls end up quite thick in Minecraft, but close. One thing we still have to resolve — and we knew this would happen — came out of testing with patients here: the main thing they want to do in Minecraft is build and interact with each other. As soon as you let people build, they can also knock things down, so there are issues around some children wanting to knock down the hospital, build fires, all sorts — all part of the fun in Minecraft. We're working through how to manage that with hundreds of patients logged on, so we're in the early days of deployment. But even that's interesting: it throws up things you might not have thought of with new tech. The real principle, if you forget all the detail, is that this is potentially a completely new way to engage with your patients. Imagine that in the Minecraft hospital you start doing cleverer things — "this is the real hospital, but we also have a virtual room here about hearts, and in it is information about congenital heart disease." That's a way of giving advice and information to patients that isn't a patient-information leaflet. There are huge, largely untapped opportunities there.

It's an interesting point. My view is that for anything like this, it's simply a risk–benefit equation. If you're doing something where the benefit potentially outweighs the risk, you should go ahead. The other thing is that at the moment we're still thinking in quite an old-fashioned way. Even with Minecraft, we're still saying, "here's a screen." But there may be other ways to interact that aren't screen-related. There are some interesting things we're trying now with augmented reality, mixed reality and other approaches to engagement. For example, I've got a PhD student whose project is around how you help people engage with their disease — and one aspect is their medication. You may have seen there are a few companies now with wine bottles you can point your phone at, and a little avatar comes out of the label and tells you about the wine. We're trying to do the same thing with cartoon characters for medications. A child can point their phone — it happens to be a phone at the moment, but it could be something else — and you get, essentially, a living bottle. The bottle itself starts telling you that you haven't taken your medication and what it's for.

So the concept is that we don't yet know which things in tech are going to work well in medicine and which are going to be bad, and we don't yet know which patient groups each will work well for. But that whole process of how you evaluate this is really important. It's a whole new branch of medical research: how do you do this properly, so the level of evidence is enough to make a proper clinical decision?

One thing that's clearly happened over the last couple of years is that everyone is much more cognisant now of the risks and uses of data. Everyone I speak to now, for any kind of partnership, is putting the arrangements up front — partnership arrangements, data-sharing arrangements, commercial arrangements. I don't know the details of the Royal Free case, but in general everyone is much more aware of the issues. And there's guidance now from NHSX that wasn't around before, so we're much further ahead than we were a few years ago.

The trickier point is that if the NHS wants to work with commercial partners — which I think it has to — there has to be benefit for the NHS and benefit for the commercial partner. If there's no benefit for the commercial partner, they just won't do it. So we have to get comfortable with the idea that it's okay for a commercial partner to benefit, so long as the NHS and patients also benefit. That conversation is being had a bit more frankly now, whereas a few years ago it wasn't. One of the things NHSX is trying to set up is what they're calling a national centre of excellence — providing advice to NHS organisations specifically on this. The difficulty at the moment is that no NHS organisation has any skills in this space; it's not something they did before. There isn't a brilliant lawyer in your NHS trust who knows all about commercial and IP arrangements, because that's not what the NHS did — but it's required now. Rather than each trust doing it, it makes much more sense for the NHS to come up with a framework. I think that's one of the things that'll be developed over the next year or so, and it should make this much easier.

My personal view is: unless it's an interest and a hobby of yours, no. But what you should be learning is the principles of coding. You should be learning about data, the principles of data science, how to evaluate tech, the hardware requirements of technology. All those things are super important, because if I just need someone to code something, it's actually very inefficient to get someone trained as a doctor to spend their time coding. I can get many people who are better at it and cheaper than you to do the code. The hard bit is knowing what should be coded, not actually writing the code. I don't want to make that sound flippant — writing the code may also be hard — but it's a different skill set that other people have.

So for doctors and medical students, the main thing you can add isn't the coding itself; it's being able to understand enough to speak to the coders. For me, the key thing in clinical informatics is being able to speak the language of clinicians and understand medical research, but also speak the language of technologists and computer scientists who can code — so that the computer scientists don't think you're an idiot who doesn't understand anything about Python, but equally the doctors don't think you don't understand anything about their healthcare problems. It's that middle space. That's the sweet spot for doctors.

The single biggest tip came from my thesis. I did it at King's with someone called Kypros Nicolaides, a professor of fetal medicine there. One of the things he said to me then is probably what's stuck with me and been most useful. Every time we met, he would get a blank piece of paper and say, "so, tell me what you've actually produced." And you suddenly realise that in your career, nobody cares that you tried really hard. Nobody cares that you worked hard and were up all night. What matters is: where's the publication? Where's the presentation? Where's the grant application? Where's the actual demo of the software you can give?

Too many people spend a lot of time but never quite finish anything. If you're writing a paper and you get it 95% finished, that's the same as zero, because it's either published or it's not. The fact that you tried really hard and stayed up all night — if it doesn't get published, you didn't do it. So whatever you're doing, try to make it much more binary: what's the intention of this thing? Until that's finished, delivered, done, you haven't done anything. That's the single biggest thing — pushing people to actually finish. It's often an extra 20% of effort that people don't put in, that takes you from having nothing to show at the end to having lots to show. So that would be my biggest tip. But there are loads of things — that's a different area.