HTN recently sat down over Teams to chat with Dr Marcus Baw, a GP and software developer, and Dr Simon Chapman, a paediatrician at King’s College Hospital NHS Foundation Trust and South London and Maudsley Hospitals NHS Foundation Trust.
Marcus and Simon joined us previously for a live session at HTN Now 2020, to discuss their Digital Child Growth Assessment programme, so we thought it was about time to catch up.
The pair, who share an interest in coding, open-source data and creating digital solutions, first met at an ‘NHS Hack Day’. Here they tell us all about how they became ‘clinicians that code’, why co-creation is essential and how the thinking behind their digital growth charts can potentially be applied to other areas of medicine.
Tell us about your roles and how you became interested in coding
Simon: I’ve been in medicine for 20 years, and I’ve been a consultant for about 10 years. I’m a paediatrician, so I work in acute paediatrics but most of my day job is with teenagers – I suppose I’m what you might call an adolescent physician.
Coding is something I’ve always done as a hobby, ever since 2010, I think. [But] when I was a little kid, when I used to go up and down Guilford Highstreet and go into WH Smith and play on the computers, that’s when I first got into it. The BBC Micro and Commodore 64…the ZX81, back in the 80s.
Marcus: I’m a GP in Yorkshire and I was quite geeky at high school and college but then didn’t do any computers whatsoever throughout all of my medical school and for about five or 10 years after that, really.
I got back into it because my brother showed me Ubuntu, which is a Linux distribution. I started learning to program again in languages like BASIC and some proprietary languages. [But] I thought I need[ed] to graduate to a proper language that people use in the real world when building software.
At the time I was working as a GP in a prison…I didn’t have keys. They had to lock me in wherever I was doing the next clinic…leave me there with a computer and literally nothing else to do. I went on Codeacademy and taught myself to programme in lunch breaks.
I got interested in problems like growth charts because there didn’t seem to be any robust digital solution. It has that in common with a lot of other areas in medicine, where there is a tricky stuff to be done but no standard implementation, nothing to make it easier for you.
The way I got involved in this is that I had written some growth chart code some years ago, and the Royal College of Paediatrics and Child Health approached me. I knew about Simon and his work and I knew that he’d done work at King’s College. So, we got together and got involved in this work, which is getting quite exciting because we’ve pushed growth charts in digital form now further than anyone ever has before.
We’ve done more of the hard work and tried to take the work away from the end implementers. Where we are with the project now is working with suppliers to get them onboarded [and] get them set up with an API [application programming interface]. So that gives them calculations, it gives them centiles, or another way of representing that is called an SDS (standard deviation score) – these are measures of how a child compares to its peers at exactly the same age in height, weight, body mass index, head circumference.
The API gives them those answers. Without that API they’d have to calculate all this themselves and it also gives them data about how to chart it as well, so they can use the API to get a nice chart, which they can put onto their website or EPR. That’s the end goal – that there’ll be good quality growth charts in every EPR and they will all use this API to do it. No-one will have to do any of the hard work – we’ll have to do the hard work once.
Now that we’ve got to that stage, we’re finding other problem spaces. Not just in paediatrics but across all of medicine.
Why will this be useful?
Simon: We think that, probably, clinicians should be closer to the code than they currently are. Most of the software that we use, the stuff I use at work, is not very intuitive. They will have people when they build these EPRs and things, they will have medics that will be part of the design process, but I think that they’re probably a bit too far away.
Probably the best value that we’ll get with APIs is things like clinical calculators, because…they’re the kinds of thing that are designed, largely, by medics. If you want to develop some kind of score, it’s usually been developed by a medic and then published.
It makes sense that if we’re going to have a suite of these kinds of calculators then they’re going to be developed by the people that invented them.
The nice thing about having it as an API is that it makes it scale very quickly. You could come up with a calculator for COVID, or something – I could image there’d be a score that says somebody does better or somebody does worse. And if you have that as an API, it doesn’t take somebody reading the study and then implementing it themselves, it takes one person do that and then the rest of the country can just use it.
Plus, it would be open-source, so then it would mean that, if people don’t like it, they can change it. Or they can have a conversation about it, and it would be in the open space. I suspect that’s where this will go.
Growth charts are unusually complicated, that’s why we get sort of the most bang for our buck here. But I would have said that I’d quite like this to embed and get used and for people to feel confident with it, before we start doing new stuff.
Ideas don’t come until you ‘see’ it. I think if you can see it working for growth charts, you might imagine it working for all sorts of other things. It’s not until you see it ‘living’ that you see what might be possible.
My feeling is that in the next five years, this might take off and people will suddenly go ‘why don’t I have an API for that?’. People don’t really know what APIs are yet.
Any other thoughts on this, Marcus?
Marcus: It’s been highlighted, actually, the importance of Royal Colleges doing this as well. People do criticise the Colleges for being out of touch and all kinds of things. But one of the things they do well is stick around; they don’t change their names, they don’t disappear and then reappear with a new leader, they don’t churn.
So actually, if you want to build stable pieces of medical infrastructure with authority and longevity, there is probably no better place in the world than a Royal College, or the equivalent…in other countries.
The idea that those organisations could move into the digital space…that’s where we’ve got to get to. Providing this infrastructure, solidly, so that we never lose it.
Royal Colleges, I think, are a fundamental part of that and open-source is another fundamental part of that – because what prevents it disappearing? Say some organisation puts out an API, then decides it’s not profitable and decides to get rid of it. Well, you can’t ever have a situation where you lose a piece of medicine.
A piece of medical information can only ever be positively contributing – it can never be taken away. When you have open-source it means it can never be taken away. If somebody decided to shut down that web service, the very same day someone else could take the code and set up their own version of it. And you’d still have that facility, maybe somewhere else on the web – but it means it would always exist somewhere. I want this stuff to be around forever.
Have you seen more enthusiasm for coding among clinicians recently, during the pandemic?
Marcus: We’ve got a little ‘clinicians who code’ forum and that’s grown quite a bit in the last few weeks.
I’m not sure if we’re seeing an effect of the pandemic and more digital stuff. For the reason that Simon said earlier on – in the rest of the health tech space, clinicians are kept away from the code deliberately, I suspect, to keep us away. We’re not necessarily allowed to have hands-on stuff and to test it and check it…I would hope to change that and get more clinician involvement.
[By] talking directly to clinicians you get excellent work. You’ll never find a better example of that than if you go to an ‘NHS Hack Day’, when we’re out of this lockdown situation and when we can have face-to-face hack days and conferences. [NHS Hack Day] is how me and Simon actually originally met…which is an unofficial, not-endorsed-by-the-actual-NHS hack day. It’s two days, over the weekend, and you turn up and you work on projects. And the great thing is that you’re a clinician and you’re sat next to a programmer and you’re talking directly about the product which is in front of you.
That is a very refreshing environment. All the clinicians that go – they can’t believe their luck that they’re getting to talk directly to an actual developer. And the technical people can’t believe their luck that they’re getting to talk to an actual clinician…the future is seeing a closer collaboration between the two sides.
Clinicians that code, I would say fundamentally, we’re not trying to suggest that we don’t need technical experts who do this full-time [and] that are better than us at programming. What we are saying is that you can’t build medical software without involving clinicians really closely.
What do you hope to achieve with your growth charts project?
Simon: The main thing is that we want to produce something that people can use. For me, the main reason to do this is to democratise growth charts. At the moment, growth charts are only available to the people that can pay for them.
There’s this push against clinicians to go paperless but the one thing that holds you back in paediatrics is you need a growth chart. Therefore, usually what happens is people pay for some sort of plug-in to their existing software – [but] we don’t know how validated it is or how good it is. It does mean there are a load of clinicians out there who don’t have access to it. So, they’re still stuck with paper charts and scanning them in. This way, everybody gets accurate numbers, it doesn’t matter where they are.
It means we set the standard at the College – and everybody else follows it. It’s a lovely little template that, in principle, you could use for other things.
Rather than thinking big, I think the way to do it is to start small…I reckon if we set it two or three years ahead, once people see how the growth charts have worked, then people will think ‘oh maybe we can do this for diabetes, or maybe we can do it for something else’.
Marcus: This is a social movement that can happen among the clinicians that want it.
Simon: It’s difficult to embed health tech when most people’s idea of health tech is their EPR…persuading clinicians to see health tech as something useful to them rather than something that’s a barrier – that to me is a massive step.
That’s why I think projects like this are good; they can see technology work for them, not working against them.
Marcus: The excitement here is not just growth charts – I want to build this sustainable movement across all of medicine. In 10 years’ time, I’d be very surprised if growth charts look like they do now…this feels like possibly one of the biggest revolutions in medical technology, if we get it right.
I think there’s a great big technical deficit between where we are currently, in terms of technical capability, and where our leaders think we are. I’d like to catch up and I think this offers a great opportunity to bring us up to a point where things like precision medicine [and] genomics are feasible, because they’re not currently…with the right development…that stuff is all possible.
