Rare Disease AI

For sure. I'm a computer scientist, so I wasn't really on the clinical side when I started. I really wanted to be a doctor before starting my computer science degree, but then I figured I could be a really, really good doctor — maybe in 10 or 20 years — if I actually became a computer scientist first. So I went for that, and things unfolded a little differently. I got into data science, then healthcare, and a bit of bioengineering. Quite quickly I realised there was another way of helping patients and having impact in the clinical system: maybe by creating a company that was looking at these kinds of problems.

I studied here in London, then I moved around a little. I worked in Tel Aviv at a startup that's becoming quite big now, called Healthy.io, where we were doing some remote diagnosis — that was my first digital health experience. After that I moved to San Francisco for a few months, and that's where I met my co-founders. While we were there, we were trying to understand what the big problems around genetics were going to be. It was really at the beginning of CRISPR, this whole idea of genetic editing, and the fact that we'd be able to sequence DNA much faster. There was loads of momentum around it.

As we started to understand what we could do in the market, we realised very quickly that in genetics you essentially have cancer on one side and genetic diseases on the other — those are the two big, actionable clinical things you can do today. And when we looked at rare disease, it became evident that the biggest challenge was the diagnosis. You have all of these patients spending years and years in the system because we just don't know what they have. When you think about it, it makes sense: rare diseases are, by definition, individually rare, so doctors aren't really expected to know the clinical patterns for all of them. It's no surprise they struggle to find a diagnosis quickly. And so you get this crazy diagnostic odyssey, where patients are pulled from pillar to post in the NHS, seeing all these different specialists for years and years.

My co-founder was a clinician, and very quickly we realised this was fundamentally an information challenge. At the end of the day, you just want the doctor to have the information that lets them diagnose the patient at the right time, in the right place. They're never going to learn 8,000 different ways of diagnosing all of these diseases — but if you give them the right information when they need it, in front of the patient, then there's a good chance we can catch it. So if we focus on reducing the diagnostic odyssey and streamlining the clinical pathway — so instead of taking years it takes months — everyone wins. The patient gets a much better outcome and earlier access to treatment. And the systems — healthcare providers, payers in the US, the NHS or the government here — have huge incentives to find these patients early, because it means less waste and less healthcare utilisation. We had a great team of four co-founders, very complementary — some computer scientists, some doctors — and slowly the team grew around us. That's really how it started.

There are a couple of ways to answer this. The super-optimistic way is that this is getting better — we're getting more and more codes, doctors are getting better at coding, and new systems let us capture more information in clinical records. So if you take a long-term view, we're going to get there. The second answer is: yes, it's challenging, but isn't that exactly why it's interesting? If it were easy, and we could already do all this analysis, you'd have more competitors and it would be harder for us to differentiate.

For a long time, rare disease was a bit neglected, because people looked at it in silos — it felt like 8,000 different niches. But with the advent of new technology, and everything that's happened in digital health over the last 10 or 15 years, the field stopped being so fragmented. We started to realise there were patterns across all of these diseases: they tend to be progressive, multisystemic, and hard to diagnose, and almost 80% have a big genetic component. So you can actually group them together and ask: let's look at rare — or hard-to-diagnose — disease as a whole, and what solutions can we build. It's a challenge, but it lets us be creative and innovative.

The first thing to say is that the number varies — it's five to 10 years depending on who you ask and which paper you read. But it's also heavily skewed, because we're only talking about patients who eventually got diagnosed. Think about all the patients who never get diagnosed, who are still looking. We speak to patients who've been searching for 30 or 40 years. And other issues start to cripple them: patients get accused of having mental health problems, because they keep going back to their doctors with weird symptoms the doctors can't see. So it's a much bigger problem than the headline numbers suggest — always remember that five or seven years is extremely skewed towards the people who, at the end of the day, got an answer.

As for why it's so difficult — I'm not a doctor, so I won't venture into why the clinical patterns are so hard. For me it's very straightforward: it's a systemic issue. We've designed medicine by specialty. Since the beginning of healthcare we've looked at things in silos — you see a cardiologist if you have a problem with your heart, a dermatologist if you have a problem with your skin.

The problem is that a lot of rare diseases break across different systems — that's what we call multisystemic patterns. So you get this medical ping-pong in terms of referrals: the GP refers to the cardiologist because the first sign looks cardiac, and then the cardiologist immediately defers to the neurologist because it also has neurological consequences. The system just wasn't built for diagnosing rare disease patients. And you can't really blame the system — it works as best it can. We just need to find a way to patch it so more people get better care. That's my very pragmatic way of thinking about it.

What we do is pretty straightforward — if you and I sat down for a few hours, we'd probably come up with something quite similar. If you want to have an impact on the patient's diagnostic odyssey and reduce it, you want to act as early as possible. So from the very beginning we said: we need to look at primary care. How do we tell the GP, "This patient warrants further investigation — go one extra step, because there's information here that may lead to a new diagnosis, or reveal a misdiagnosis, or point to a better referral or clinical pathway"?

As medicine becomes more digital and we can look at populations at scale, population health takes on a completely new meaning. You can now say: let's look at 5, 10, 20, 60 million patients in one go, scan the clinical records, and highlight the patients who are pre-diabetic — or whatever it is. We're doing that for rare and hard-to-diagnose disease. We go into practices, GPs, CCGs or regional organisations, request access to the clinical records of a population, and build models that sift through those records and match the patients who should be flagged to their doctors. In most cases these models already exist — they're in the brains of the top consultants who really know these diseases. The problem is we just don't have that many experts, and they can't see the whole population.

There's an interesting anecdote here. If you look at a map of where rare disease patients are concentrated in the UK, you'll see they cluster around the centres of expertise. And that's not because more sick people happen to live next to the centre of expertise — it's because only the centres of expertise have been able to diagnose these patients. The people who live in the countryside, or who don't live near Great Ormond Street, aren't being diagnosed. So you have a health-inequity issue — what the NHS calls the postcode lottery, where you get different care depending on whether you happen to live near a top hospital with the right expert. With around 8,000 diseases, where the metabolic expert is over here and the super-niche expert is somewhere else, you have no good way of finding all these patients. So that's what we're doing: democratising the expertise of how to find these patients earlier, by scanning medical records, flagging whoever breaches the established thresholds, and letting the GP know so they can act.

The general challenge is that it's a challenge — let's put it that way. It's not easy, and it's definitely a hard one. The NHS can be improved in so many ways, but it's a system that works and does the best it can. It's very complex, so the reason it's hard to innovate within it is, in a way, justified. There's no way to hack around it — you're never going to get data from the NHS by not filling in the boxes. So for me it's just an exercise in checking the boxes: really understanding, with a lot of empathy, who's on the other side of the table. When you talk to the commissioners, the CCGs, the clinical leads — understand what they want, what they need to see from you as an innovator before they'll implement your solution. Remember they're human beings, like us; they have their incentives, and they have to report to their managers. Ultimately we all have the same goal: to improve patient experience and outcomes.

I wish I had a silver bullet, but it took us three years to really crack it. About a year and a half ago we got our breakthrough and started running clinics, and now we're ramping up. It's still very hard. You have to take a pragmatic approach, because you're in front of very pragmatic people who want your evidence, your health economics, your ethics. So you go home, work hard, and keep providing that until they don't have any other excuse than to say, "Yes — let's help patients together."

A five-year-old or a medical student — I feel that's quite a different audience. Let's go for a 15-year-old, maybe that makes the cut. There's an easy way to think about it. We put all these words — machine learning, AI — on top of what we do, and that's been the DNA of the company from the beginning; we've been very careful to use and build the right models. But when you're in front of the NHS providing your solution, you have to be extremely clear about what you're doing. If you can't explain it to the commissioner, it's going to be very hard to get anywhere. That's been our experience.

So without too much technical detail: there are existing ways of diagnosing these patients — clinical criteria — that currently live either in written form or in the brains of top clinicians. The idea is to digitalise those criteria, encode them so they're ready to be used at scale in a digital healthcare system. Then you put safeguards on top, and a framework that constantly checks for new ways of diagnosing these patients and new features to find them. You do that by looking at already-diagnosed patients, at publications, by talking to patient advocacy groups and interviewing the experts and doctors. Then you let the model do its work — adding a bit of conditional, decision-tree, logic-based modelling on top, and using natural language processing to process publications so you can gather as much information as possible. You end up with a model you can apply to a large set of clinical records.

Oh, 100%. But you also have to realise the models we use aren't the same. The models you're describing — the fancy deep learning that Google is working on, the "deep patient" style publications — of course those need a large amount of data, a large number of cases to teach the model what the patterns are. In our case that's just not going to work, you're right. And again, that makes it interesting, because we have to be creative and maybe go back to simpler systems — more ensembled techniques that gather data in different ways.

The system we have in the NHS today is much less fancy than what deep learning would be. It's a matter of logic-based rules, conditionals and decision trees: if this is present, and this is present, and this publication says this could work, then you build a set of features you can apply at scale. It's a challenge, and the future will tell us how long it stays one. There are some interesting new models that use much less data, but they're still very much in the research sphere. We'll see how the field evolves.

It's interesting, because the problem is that synthetic patients have to be based on something — you have the same issue. You need to base them on existing, real patients. So if there are only five patients for a very rare disease, how are you even going to create your synthetic dataset? It's the same challenge. I'm not an expert on synthetically generated data, but systemically the same problem applies: if you don't have enough examples, it's hard to generate as much data as you want. Synthetic data is really more of a randomisation of the data — you use it more when you want to make sure there's no identifiable information, so you anonymise the dataset by randomising and changing some sets of features across all the patients you have. We've looked at it, and we keep monitoring where it's going, but it's not something we can use today.

There are different ways NLP can be used, but the whole goal of the technology is to understand human language and put it into a machine-readable format. A computer can't necessarily understand everything we say or write when it's in free-text form. If we structure that information — code it the same way doctors code clinical records — then it's much more usable, because you can attribute it to a code, and that code sits within a hierarchy, so you understand where it fits. In a purely biological sense, you understand how signs and symptoms relate, because you can link them within a hierarchy: everything related to pain sits under the group "pain". You can give them different weightings, and the machine understands that properly.

But if it's free text the doctor is writing next to the structured fields — nuancing the symptoms, describing something that doesn't fit the structured format — the goal is to understand that information too. NLP is quite an old field; it's been around since the very beginning of machine learning, even before AI was a thing. The idea is to categorise the way human language works so the machine can understand it better. In a publication, a sentence will have a subject and a verb, explaining how one thing relates to something else. You teach the machine the rules of human language so it can link those two things. At a high level, you apply these models at scale across every publication, asking the machine: can you tell us the relationship between this particular sign and this variant of that gene? Then you let the NLP run and see what it picks up.

Sometimes it's as good as it gets — it's not perfect yet, but we're slowly getting there. You train the machine by giving it as many examples as possible of how these sentences are usually written. And you can clearly see that when sentences are verbose, or grammatically odd, or a bit adventurous, the machine fails to understand them — because it doesn't have enough examples, or it looks odd compared to the norm. We've been using NLP techniques for years — pipelines of different technologies, one after another, each augmenting the machine's understanding of how language works. You can add pipelines that look specifically at research papers, because they tokenise certain words differently, then let it run, look at the data, and use good controls to make sure you're getting reliable information.

Theoretically, you could. The question is whether the machine would understand features that are actually relevant to you. Say a disease only appears in males, and you give it 40 cases, all male. You then ask the machine what sex the patient has, and it says, "I'm pretty confident that to find a diagnosis, this patient needs to be male." Great — your machine's been trained and it can give you that conclusion, but is it useful? Is it a feature you didn't already know?

That's the issue: you need scale, because the whole point of doing this is for the machine to understand things we haven't been able to understand ourselves. Think of it as a multidimensionality problem. You're no longer just looking at sex, age, progression, the systems it affects. You're looking for categories I wouldn't even be able to name — because, by definition, we don't know what they are — different features that are sometimes mixes of categories. That's the key. So theoretically, yes, that's how it works: you give the machine examples and wait for it to hand you back rules that classify the population you gave it. But will you learn something from it, if it's a very small dataset? That's the real question. And if you do — please let me know.

It's a great question. We've done both in the past — we've had products that gave you an exact probability. But it's very tricky for everyone to understand, especially if you're using black-box models where you're not really sure how it's performing. It gets complicated fast. In our current implementation we're nowhere near that. We know what the rules are: if you have these signs and symptoms, and the patient is within this age range, or other features a doctor would understand, then you calculate a score, and you can explain exactly why this patient has been highlighted.

This is something we hit ourselves over the head with the first few times, because we came to doctors with all these fancy algorithms and they'd ask, "But how do you know? How do you explain this?" Slowly we realised it's much simpler to take the low-hanging fruit — use the existing ways of diagnosing a patient and just scale that process — rather than build models that sometimes not even the engineer really understands. So we're firmly on that side today. When we flag a patient back to the GP, we can clearly explain why, we can provide the source, and we can link it to the clinical pathway: "Here's the patient, here's what we can read in the clinical records, here are the publications we found about how to find these patients, and here's what we'd recommend doing based on the prognosis." That lands much better in the mind of the clinician.

It's such a dynamic field — there's something happening every day. Pharma are hugely bullish on orphan drugs; I think only about 5% of rare diseases currently have a treatment, so there's massive room for improvement there. There's a lot to do on communication around these diseases — helping patient advocacy groups organise all the knowledge they have, and there are already some companies doing amazing work there. And there's the clinical trials aspect. In rare disease, trials are quite special, because you might run one with 5, 10, 20 or 30 patients, and recruitment is very difficult — you have to go and find that particular patient. So there's a lot of improvement to be made around recruitment for rare disease clinical trials. But honestly, it wouldn't take anyone long to see how much more can be improved in the space. If anyone has ideas, I'd be very happy to discuss them.

I don't know if there's a particular principle I apply. We're a very small company, and you always have to be aware of what your advantages are. Ours is that we're small, which means we can be fast. If we have to compete with anyone else, the only thing we can do better than them is work harder and be faster. So I apply that philosophy: if you can send that email today rather than tomorrow, just send it today. If you do that across all your interactions, you've already won two weeks' worth of delay. And when you're dealing with big institutions like the NHS, pharma or the government — our main stakeholders — it makes a big difference to show that you're fast and lean. That's something I try to apply to myself, and I'm getting better at it.

2020 has been a very interesting year for everyone. Without mentioning the magic word we haven't mentioned yet, I think it changed everything — but honestly, I can't complain. It's been going really well. Productivity hasn't dipped much; we've been very busy over the last few months. We don't have a wet lab or anything like that — everyone's working on their computer — so if you enable people to do their work in the best way and make sure they always have what they need, that's what we've done. Many companies are in the same boat; there's nothing revolutionary here. To be completely honest, we're not entirely sure what happens next — whether we go back to a physical office or ride the remote wave for a long time. The reason we're still hesitating is that we haven't seen much difference in productivity. It's definitely been less fun to go to work, and I miss the interactions — we have an amazing office and share it with other companies doing amazing work, which is so inspiring. But at a pure company level, it's been going really well.

We're definitely not doing a four-hour work week. I'm currently based in Mexico and I move around a bit — I was in the US before that. I have to wake up very early to be on UK time, so I'm up at 4am. Maybe that's what you mean by the 4am work week — but we're definitely doing more than four hours a week. As long as you have your processes in place and a team that understands what needs to be done, things go pretty well, because communication within the team is good. Every day we have a standup — we used to stand up for it, now we stand up in front of our computers, I guess — and we chat for about 10 minutes about the goals of the day. Then we have a sprint, which is the planning of tasks over the following week or weeks. We don't have that many meetings, because we're still small, so when you're working on something you just grab the two or three people you really need and get to a decision quickly. That reinforces what I was saying about being fast — you never have to say, "I need to tell you about this, can we plan a meeting for next week?" That never happens. But again, that's more a benefit of being a startup than anything else.

I read one book quite early that really helped me on many levels, and it was very surprising. My co-founder gave it to me — it's called The Goal). There's a big debate online about whether you should read fiction or non-fiction, and this is an interesting one because it's fiction — a made-up story, a novel written about management and how to run a company. There's a guy who's supposed to manage a factory and all sorts of things happen to him. It's an effective way to tell a story — as an author it would have been fun to write, because you can have anything happen to that person and teach your philosophy of management through what happens to him.

There's this idea running through it about bottlenecking — de-bottlenecking. The character has to run an actual manufacturing factory, with a conveyor belt and things I'm quite foreign to, and you realise there are loads of processes comparable to what you do all day. When you're managing a team, what you really have to do is de-bottleneck — make sure you unblock everyone and every situation that arises, so everyone can go faster. There are loads of interesting elements to that book. I really loved it, so I'd recommend it.