Open Source is the Future of Medicine

So in the 1700s, this family — the Chamberlens — had secretly invented a pair of obstetric forceps, quite similar to the ones we use to this day, a bit like Kielland's forceps. They come apart, so you can get one side in and then the other, then hold them together and do an instrumental delivery.

We don't know how many deliveries they performed that way. They did this service for heads of state, royalty, rich people — and they kept the forceps completely secret. Nobody knew how they were doing it. People knew the Chamberlen family could save women in obstructed labour, but no one knew how. They kept that secret successfully for over 100 years, and at some point the forceps were discovered underneath the floorboards of a house they'd previously lived in.

It struck me as a complete parallel. When you've got closed-source software that does incredible things for medicine but you don't release it to the world — you keep it proprietary, you prevent other people having it — you are committing a crime against humanity. That's what the Chamberlens were doing. Think of how many women died in obstructed labour over the 100, 150 years they kept that innovation secret. Probably tens, if not hundreds of thousands of women, and children, would have died — and some of them could have been saved by the knowledge that that innovation existed. But it was kept secret by some obviously misanthropic, horrible people.

So that's why we've got to make everything in medicine open source. Because you don't want to be looked back on by future generations like the Chamberlen family. Imagine you developed an algorithm that's closed-source and could save lives, but you don't share it with the whole world. I wouldn't want to be that person.

Sure. Open-source code just means you've given access to the source code of the program. So what do we mean by source code? When you get a program — most people have a Windows or a Mac computer, or a device that runs apps like an iOS device — you download an application to that machine. It's kind of a black box: in most cases you can't get at the code inside that shows you how it works. You can use it, and we all do — we use closed-source applications all the time and assume they work — but there's a significant problem on the engineering side when it's closed-source, because you can't see how it works, and you can't check how it works. You can't prove it's safe. There's very little way of providing oversight or scrutiny.

That, to me, in the context of medicine, is completely against the way we practise medicine. Because if you look at how we handle new developments in medicine, you wouldn't get away with saying, "I've invented a new surgical technique. Trust me. It works. I can't tell you how, I can't show you how, I'm not going to let you watch the operation — but it definitely saves lives. I'll go in, keep the doors closed, and give you a patient afterwards who's cured." You'd be laughed out of medicine. If you want to develop a new surgical technique, a new drug, a new anything in medicine, you have to show its scientific plausibility. You have to show there's evidence it might work. Then you start doing trials, on animals and then humans.

And then it might become more accepted, and you build up a bigger and bigger body of openly published evidence. That's all like the source code — the source code of your surgical technique: how it works, why it works, proof that it works. If you do all that, it gets absorbed into medicine, and something new can come along that we didn't have before. We're all completely happy with that for medical interventions. But with the software we use in medicine, we seem to have forgotten that we need to apply that same level of rigour. So there are lots of problems with medical software: we don't have evidence that some of it works, we don't have evidence that some of it is safe. Open source is a step towards fixing that. It doesn't provide everything I've talked about, but it does provide some of it. Imagine I've built an algorithm that searches through millions of records and tells me the ten things a person is at risk of. If it's a closed-source black box, how do we actually know it's right?

We have only the say-so of the manufacturer, and we just have to trust them. This is really topical, because whenever I see AI in medicine being pushed, I hear snake oil. AI, machine learning, all that stuff — it's pure snake oil unless you can show how it works and give evidence that it does work. At the moment it seems to be an area where there's a lack of rigour.

Take the opposite scenario. If I've got an open-source algorithm that gives you a risk profile for a person, then other researchers can look at my code and say, "you've made a mistake there," and we fix it. So the standard gets better, because we're all working towards improving safety. We can all see the source code — we get better safety, a better evidence base, we get scrutiny. Other things happen too. If I've made an open-source algorithm, I can't charge you a billion pounds per patient, because the market prevents me from using it as an extortion tool. But with a closed-source algorithm, I absolutely can. You're locked in. And if I decide the price is going up 1,000%, you just have to pay it. End of story. Open source doesn't prevent a commercial marketplace from existing — it creates a fair one. One of the criticisms often levelled at open source, by people who don't really get it, is that it's some kind of wacko, extreme left-wing, hippie-commune software that only socialists use. That's just rubbish. There are many huge examples of companies with an open-source product that do really well. The best is probably WordPress. Everyone's heard of WordPress as a content-management and blogging platform. WordPress is open source. WordPress.org owns the source code, but there's a whole service industry around it — 30-odd percent of the whole internet runs on WordPress. That means there are probably millions of people who make a living through it, from sole traders building websites for the local shops, up to medium enterprises doing big corporate sites, right up to the biggest sites.

WordPress themselves provide services around that, but lots of other people can too. It's created a community — an ecosystem — where you can have players of all different sizes offering all different kinds of services around one common platform. That's an open-source utopia, and it's real. Discourse, the forum software, is another good example. Red Hat, a Linux distribution, is another. There are hundreds of people providing services. So open source is pro-commercial. It just has a different model of commercial. It's not about starting up, making your first couple of million, selling your shares and exiting the market. It's a more sustainable marketplace, where you get involved, have some skin in the game, and build software as a community.

It's interesting, because I'm actually not going to argue that medicine is different here. I'm going to say your Tesla is open source — because everything physical, any physical piece of engineering, can be reverse-engineered fairly easily. Software is unusual, which is why we need a special kind of software called open-source software.

Software is unusual in that it's a type of engineering where you can hide all the workings. When you download your app — your .exe file, your iOS app, whatever — it's a black box and you can't see inside the wrapper. It can sometimes be possible to reverse-engineer out of those wrappers, but it's hard. Whereas pretty much any machine you can name — a bridge, a Tesla, an amplifier for a guitar, whatever consumer electronics you like — you can take it to bits. So everything, until we got to software, all of engineering was open source by default. That's why we didn't even need a word for "open source": there was no other way. If you were an 18th-century steam-engine designer, your competitor just buys a steam engine off you, takes it to pieces and works out all the secrets. That model has always existed.

There were a couple of complications when software came along. One is that software is regarded as a creative work rather than a work of technical innovation. Technical innovation is covered by patent law — that's how you protect your intellectual property if you've built a physical object. If I build some revolutionary new engine, I patent it, and that gives me protection so no one can copy me for a period of time. Usually not long — seven, ten, fifteen years maximum of exclusivity. After that, people can copy it. And it's fundamental to progress in engineering that after some period your exclusivity expires, so others can commoditise what you've built and make it cheaper. That commoditisation is what drives prices down. You get your ten years of exclusive profit-making, and then it becomes generic.

In fact I've used the word "generic" — this is exactly what happens with drugs. You have your period of exclusivity, you make all your money while it's a branded drug, and then at some point it becomes generic and everyone can make it. You can carry on making it, but you're no longer the exclusive patent owner. We fought hard in the early part of the 20th century, as a profession, to get patents applied to drugs so they couldn't be permanently proprietary. Imagine where we'd be if all drugs were permanently proprietary and there was no such thing as generic atorvastatin. You make all your money while it's branded Lipitor — which is what atorvastatin was — but if there were no generic, we couldn't afford to give it to the number of people we give it to now. You'd have impaired progress.

So that patent stuff is about progress. Whereas people in the tech industry think having everything closed-source and making billions is progress — they're wrong. What they're actually doing is making a lot of money in the short term, and that gives them a bigger voice. But their voice is being used to imply they're leading the edge of progress, when actually, by closing things down, they're preventing it. And it won't be obvious for another ten years — the progress we've lost.

Going back to your Tesla example: that Tesla's open source. I can buy one, take it to bits on my driveway, get every secret out of it. The only bit I can't get to is the software. If that's closed-source, I can't really get at it. And this is why it's so fundamentally important to understand what open source means in a wider societal context — how it relates to pharmaceutical patents and engineering, and to progress, and to medicine and the very open way we do things in medicine. Whenever I've talked to people about open source, clinicians tend to get it straight away. They go, "you mean, you do software like you do medicine?" Yeah. That's it.

You're right that the majority of platforms we use every day in medicine are closed-source. The reason is probably just historical. The open-source movement started in the 1970s but didn't really get going until the '90s, when you got open-source operating systems like Linux and lots of open-source programming languages. So I think our closed-source medical software is a legacy — not a deliberate choice, just a hangover from a bygone age when that was how things were done.

Actually, the way to make your mark now, if you were launching a brand-new startup, would be to be open-source — purely, if nothing else, because it's the ninja move in terms of publicity and marketing. There are a lot of people in healthcare who believe in open source and want to buy something open-source, but they can't, because there's nothing there. So if you came to me as a startup and asked, "what's the one thing that would differentiate us from every other platform out there?" — I'd say, be open-source.

Now, it's a leap of faith, because you might think, "we could do all this building — what's to stop someone taking our product and selling the same service?" And I'd say: that's what you want to happen. You've got to break away from the idea that selling something means 100% exclusivity. What you want to be is one of the fish in a very large pond, not the only fish in a tiny pond. The UK healthcare market is quite buoyant — there's lots of money in it, but it's not that big. There are a certain number of players and lots of systems, but none of them are really market-dominant. General practice has a duopoly of two main system suppliers, but outside of general practice, in the rest of the NHS, you've got lots and lots of small players. Nobody's managed to crack that glass ceiling of being semi-ubiquitous. I think an open-source platform could get there.

What you do is put yourself out there and say, "we're building an open-source suite of tools for running the back-office stuff of a hospital" — the patient administration system, the order comms. These are boring, simple things nobody wants to spend a lot of money on. You just want them to be there and to work. Open-source versions of those tools would be lapped up by trusts. And as you produce the tool, other people in the marketplace might also provide services for it. Now the pond's getting bigger. You're one of several fish in a much bigger pond, all working on the same platform, and you've got momentum you can't buy. That's the ninja move: go open-source.

So it's a very viable business model, in healthcare too. You're not going to make 100% of all the money made with that platform — maybe you only make 10% — but if the market is 100 times bigger, do you care? You've still made a lot more money. It's really key to break away from exclusivity as the only business model. You're right that a lot of entrepreneurial teaching is around your intellectual property being so key that losing it seems like shooting yourself in the foot.

That's exactly what I'd recommend. Stick it on GitHub. It's probably worth a little discussion of what open source means legally, because open source is not the same as just giving your code away. It's all based around a licence you grant to other users. I've written lots of open source — it's all on my GitHub, and I don't have any closed-source software anywhere; I refuse to be involved in it. If you put it on GitHub, you still hold copyright over it. It's mine, I wrote it — it's all copyright Marcus Baw. But it comes with a licence that says, "you, the user, can use the software, and because I'm an open-source developer I'm giving you a copy of the source code to do what you want with." And I have a lot of control over what the licence says you can do.

Open source comes in many flavours, from very permissive licences that say you can do anything — "this software is copyright Marcus Baw, open source under an MIT licence (Massachusetts Institute of Technology), comes with no warranty, do what you want with it" — right across to quite restrictive licences that spell out your responsibilities as well as your rights.

What you're really trying to prevent, in the caricature you gave me, is somebody in the middle of your R&D just taking your idea, doing it quicker, and stealing it. Well, firstly, that'd be illegal, because you've copyrighted it. You happen to have published it, but there's lots of copyrighted work that's published — every book in history is published and copyrighted. We're used to the idea that you can publish something but exert copyright: you can't take my book and pretend you wrote it, because I'll sue you. It's exactly the same for open source. So there are protections in the open-source world designed specifically to prevent your idea being stolen.

What tends to happen, though, is that because you've taken the first step of trusting people, others come back with an attitude of trust. That can lead to free contributions to your software from the community. Say I've got a stroke algorithm, I've written it up, I've got proof it works, it's in a repository on GitHub and people are using it. Maybe someone comes to me with an improvement — they don't want to run the whole algorithm themselves, but they have enough expertise as a stroke clinician or researcher to tell me the one improvement to make for version two. They'll quite often just say, "here, you've given us a free tool we could use with trust, and we trust you with a contribution back." It sounds very hippy-ish and too good to be true, but it does happen — that's exactly how a lot of open source works. I've contributed time back into open-source projects, not even big amounts — sometimes I'll find a typo in their documentation and fix it: "here, I've fixed your typo," and now that's one less thing the author has to do. If you've got thousands of people contributing back, like in big open-source projects, then all the bugs get spotted by somebody.

And many eyes make all bugs shallow. That's a quote from Linus Torvalds, founder of the Linux kernel project. You've got this collaborative approach, much better for building safe systems — which is what we want in medicine.

It's no more difficult with an open-source project than with a closed-source one — and it's probably easier, because some of the stuff around warranty and being provably safe is much easier with open source. If I've built an algorithm, you can go and look at it. You can't do that if I'm closed-source. So open source is way better for this.

What you're right about is that you do need some kind of organisation to provide the service. That could take many forms, and the organisation I'm working with at the moment — which I think might provide a model for the future — is a Royal College. Who better to set standards around a stroke algorithm than the Royal College of Physicians? They could own the algorithm and provide it as a REST API — a web service where your EPR sends a request saying, "please give us the stroke score for this person," and the API sends the score back. And we've done exactly that. We have live code, which I presented yesterday at the RCPCH conference. The Royal College of Paediatrics and Child Health was commissioned by NHSX last year to build digital growth charts. Growth charts are one of those difficult things — a complex statistical algorithm. No EPR vendor has ever successfully built a decent-looking digital growth chart that does everything you want. You want to put in the height, weight, age and sex of a child, throw it at the API, and get back a chart to look at, with the centile calculated for you, the standard-deviation Z-score — all the tools a paediatrician wants, without having to do it manually on a piece of card, which is what they're stuck with at the moment. And we've built that, in open source. It's on github.com/rcpch — all of the RCPCH's code is there, with open documentation.

We've actually gone even further than most people on the regulation side. Let me let you into a little secret about device regulation: not a single bit of it is worth the paper it's written on, except perhaps the highest classes — implantable defibrillators and the like, where they actually have to be independently verified. For almost every other class — class one, class two — you basically mark your own homework. I know, because I've done all of this for devices. So I want to go further than just saying, "yes, we signed a bit of paper for an EU Declaration of Conformity, now can I have a CE mark, thank you very much." I want to be able to demonstrate safety all the time. So with the RCPCH growth charts, every time we change any bit of code, it throws 4,000 fictional children from a test bed at the API and checks that none of the answers have changed. We've pre-calculated the correct answers using a different package, so we have all these children with their heights and weights and we know the right answers — we throw all 4,000 at the API and check nothing's broken. That's a much better guarantee of clinical safety than any number of pieces of paper signed by the MHRA — especially now, because post-Brexit medical-device regulation is completely bonkers. It's all changed.

I've spent a lot of time on advocacy, and I'll keep doing that — I talk about open source a lot. But the most powerful thing you can do is just show it. Show the thing. In the RCPCH example we've got a successful project at national scale being adopted into real EPRs right now — GP systems, neonatal systems, and full-scale EPRs, even the biggest in the country — and all the digital personal child health records, all the e-Red Book equivalents, are adopting the same charts. So we have a single national standard coming out from the RCPCH, hosted by the RCPCH, defined and open-sourced by the RCPCH. And not only that — it actually generates a small amount of revenue for the College.

So this is a plan with no drawbacks from a College's point of view, because the one thing they always struggle for is money. If you can show them how to make a net-revenue-generating system out of best practice as code, you've won them. Plus, the clinicians love it. How long have we waited for digital growth charts — as paediatricians, as GPs? The College has finally found a recipe that can negotiate the difficulty of building this and getting it into the right places, because the NHS is a very difficult place to sell into. If you tried to do a startup that owns digital growth charts, you might get lots of VC funding, but you would not get market penetration in the NHS. Whereas doing it this way — open source, API-driven, integrator-friendly, and from a trusted source like a Royal College — I think that's how we get more open source out there.

Because if it catches on at the RCPCH — bear in mind we've done one API, and we've now been asked to do two more, for diabetic ketoacidosis and epilepsy — then before long someone from the Royal College of Physicians or the Royal College of GPs is going to ring me up and say, "you know what you did for them? Can we do that too? I want all the scores GPs use — QRISK — I want to get an adult BMI, some clinical decision support, all these tools that are badly provided in our current systems, well provided by the colleges." And gradually it filters out everywhere. Once you start making the case for open source and it becomes a bit standard, then it's easier, and you don't spend so much time having the discussions we've had — where really I've spent a lot of time vanquishing the fear, uncertainty and doubt that's built up around open source. When in fact, taking you right back to the beginning: it's not open source that's different here, it's closed source that's an aberration. There's no other part of engineering that has anything like closed source. The nearest you'd get is if I built a circuit board and didn't want anyone to see how, so I encased the whole thing in black resin — I know of a guitar-amplifier manufacturer that actually did this, because they were so worried about people stealing their circuit-board layout. That's the closest you can get to closed source in a physical setting. Everywhere else in physical engineering is already open source. So we shouldn't be having conversations about fear, uncertainty and doubt. Open source is the default. It's the past, and it's the future. We're just going through a growing pain — we've just got to cast off closed source, and everything will be fine.

The good news is there's kind of no wrong next step — anything you do will be valuable. If you're a clinician — a medic, a nurse, any professional allied to medicine — your clinical knowledge is your superpower in this area, so you've got to get that up to scratch. Finish medical school, do some kind of specialist training, and it doesn't really matter what, as long as it's something you believe in. But all along the way, keep your eye on what's going on in the systems you use. One of the simplest things you can do is, if you find a bug or a problem, make sure it's reported all the way up the chain. And at that point you'll discover how difficult it is to report problems with the systems we use — and how the safeguards we think we have around clinical safety just aren't there. The organisations in charge of clinical safety are asleep at the wheel. But that's one thing you can do: report bugs, talk about bugs.

There are many forums now where you can talk about these systems. I'll put some links in the show notes, but the Digital Health Networks is one. You can join the Faculty of Clinical Informatics — they have a discussion forum in the Digital Health Networks. If you're a GP interested in this, you can join the RCGP Health Informatics Group, another way into the policy and high-level informatics themes — SNOMED coding, data flows and so on. And if you're more interested in the coding side, that's a very egalitarian world, and it's really easy to start learning to code. You can go to sites like Codecademy — that's C-O-D-E-C-A-D, not "Code Academy", without the second A — and teach yourself Python, JavaScript, HTML. Those things are fun anyway; you might just find it interesting to know how websites go together and how servers work, and that leads on. Follow the trail of breadcrumbs into whatever interests you. And by all means, if people have specific questions and want to reach out to me on Twitter, I'm very happy to talk to people starting off — or even changing or mid-career — about this stuff. I'm @marcus_baw on Twitter.

Because the career path isn't tightly defined at this stage, it's a very broad church, and there's lots of scope to get involved. So nothing you do would be wrong.

I will caution against a couple of things. There are quite a few national programmes that direct clinicians who want to get into technology towards "innovation fellow" or "entrepreneurship fellow" type roles. I'm sure those schemes have value, but I haven't seen outputs from them revolutionary enough to justify their cost and scale, and I've seen some really good people just waste time in them. Another one I'm very uncertain about is the NHS Digital Academy. I think they missed an opportunity to build the biggest open-source repository of clinical informatics and digital knowledge. They could have built an open knowledge base — but no, they built a closed one. That's a real shame, because no other part of medicine has a closed knowledge base where only selected people can learn it. Medical textbooks are available to everyone; even if you're not a doctor you can go and read one — you can't practise as a doctor, but the knowledge base is at least open. When you create a closed Digital Academy, or any kind of closed cadre or club, it worries me. I like to see information free — which is what information wants to be. That's why we spend so much time paywalling it, trying to prevent it from being free; academic journals are a good example. So try not to get involved in any of the dead ends. The future is open source, without a doubt. If you spend any time in the rest of the tech world outside healthcare, everything that's good is open source. It's almost how you know it's good.