Open source has permeated much of the software industry, but what about healthcare?
This highly regulated and important industry might seem to be the domain of huge specialized
software companies. On this episode, Fred Kingham is here to introduce us to a project called
Opal. It was born out of NHS Hack Days in the UK and is a full-stack web framework for building
healthcare applications. It's based on Django and has a ton of interesting features as a framework
in general. This is Talk Python to Me, episode 241, recorded November 30th, 2019.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem,
and the personalities. This is your host, Michael Kennedy. Follow me on Twitter where I'm at
and Kennedy. Keep up with the show and listen to past episodes at talkpython.fm and follow the show
on Twitter via at Talk Python. This episode is sponsored by Linode and the University of San
Francisco. Please check out what they're offering during their segments. It really helps support the
show. Hi there. Thanks for listening to this episode. Before we get to the interview, I have
something to share with you. We just launched a new course. It's called Python for Decision Makers and
Business Leaders. If you're a team lead or deciding whether to use Python for your next project,
or even the next stage in your career, this course is a great fit for you. It's super unique. Most
courses teach you how to program with Python. This course is a guided discussion and exploration of
the Python ecosystem through the lens of your organization and your team. It's full of fact-based
presentations for the Python ecosystem, covering things like frameworks, types of apps you can build,
developer jobs, and more. And it explores some of the tools making Python so popular in the data
science space. It's written both for developers and non-developers alike. So check it out at
talkpython.fm/decision or just click the link in the show notes. But wait, there's more. I'm working
on a few interactive events as well. So I'm putting together this live event to help kick off the course.
It's a free webcast on an interactive platform with lots of QA that's happening in January of 2020.
Check that out at talkpython.fm/python dash decision dash webcast, or just click it in the show
notes. Go ahead and register now. Hopefully you can make the live event. But if you can't, you can
still ask questions, participate in polls and chat. All that stuff will be available on demand afterward
once the recording is there on that platform. Super fun. So I hope you love both of these things,
the course and the webcast. Now let's get onto that interview. Fred, welcome to Talk Python to me.
Hi. Hey, it's great to have you here. We're going to cover some stuff that, you know, I don't think
we spent any time on the show before. Healthcare and open source. It'll be fun. Sounds great. Yeah.
Yeah. Now you guys are working on this project called Opal, which has an interesting origin story
out of the UK healthcare industry and whatnot, which is great. And lots of Python involved. But before we
get into all that interesting stuff, let's start with your story. How'd you get into programming in Python?
I started programming on the Atari ST, that venerable computer of the 1980s. I was using something
called Stoff when I was sort of like seven or eight, you know, when you're creating little
games, drive the L's through the X's, that kind of thing. Right.
Full of go-tos, go-tubs and all the joys that come with it. Then I did a philosophy degree and I did a
conversion course into a master's conversion course into computer science.
Wow. Philosophy to computer science, huh? That's quite the transition.
It is. But I don't know. A lot of people, I know a lot of people who've done it.
Yeah.
I think there's something about conceptualization, maybe formal logic. There's a whole branch philosophy
called, what's it called? Logical atomism, I think. Which tries to structure, tries to work
out Boolean responses to arguments based on conjunctions. Sort of like, if I like trees
and people who like things are liked, somebody likes me. That kind of weird sort of set logic,
very Russell-based.
Right, right. Is it true that I do this or does it follow that I do this? Yeah. Yeah. I think
actually, now that you say it, there's a lot of thinking. You know, I studied math. I didn't really
do much programming. I took a couple, like two programming courses in college for little sub
prerequisites. But I don't feel like I do math at all these days, even though I was in a PhD program
working on it, right? But I feel like that process that I went through, the type of thinking and the
way of approaching problems and all that, like, I use that every day. And that seems like it came straight
out of there, even though I couldn't do math to save my life these days.
Yeah, exactly.
All right. Before we move on to philosophy, who's your favorite philosopher?
David Hume, who is the father of empiricism, who, he writes very interesting books about
skepticism and causality, the notion of how do you know if something is connected to that,
to something else? You know, causality does causality equal causation, does correlation equal
causation. And his books are very readable, and I highly recommend them. He writes them as a
discourse between, like, two or three people quite often. Discourse is concerning natural religion,
I think. Dialogue concerning natural religion, exactly.
Yeah, that's a tough question. There's so many choices throughout the years. All right,
so you studied philosophy, and then you did this conversion course over to computer science,
huh?
I finished my philosophy course, I went traveling for a bit, had a small little accident, ended
up in a hospital for a bit, came out of that, did a master's conversion course, went into
banking, because it seemed like a good thing for five odd years. Sort of Wall Street, I guess,
the investment side, what we would call the city. And then I did some contracting for a few
years for sort of marketing companies, you know, marketing websites, that kind of thing. And then
I went to NHS Hack Day, which is a series of hack days that exists in the UK, where clinicians come up
and they're like, we have this problem. At the moment, there's nothing available at our hospital.
In a weekend, can you sort of push something out so that I can take it back to my hospital IT
people who are saying, we can't have this and say, well, these guys have done something similar
in a weekend, make it happen kind of thing. Yeah, exactly. Like, it's so funny that sometimes
that's the way it is, right? Oh, you can't do that. There's no way. This is impractical. Do you
know how long this will take? Yeah, it'll take a couple of weeks. Let's just do it. And you know,
like, sometimes the debate about whether something is possible takes longer than actually doing it.
But you need this sort of outside perspective, right? So this NHS Hack Days, what is the goal? I mean,
you said the goal is to like, show what is possible. Is the goal to go there and try to like,
learn what is needed to maybe I could do a startup? Is it a charitable thing? Like,
I want to create the software and I want to give it back to the health industry in my country to just
help everyone what's going on there? It's quite open source. It's not really about the businesses,
people have tried to launch businesses based on the ideas that have come out of it. People,
some people go there to learn, some people go there just to learn, you know, experiment in
technology. It's quite a common reason to go to Hack Day anyway. The idea is definitely to make the NHS
better in this country or healthcare better. But as I say, people have tried to make companies out of
their stuff on one side. But on the other side, there's a one in one of the first one, a great
example is people who essentially have to type in like a series of strings based on whether they see
certain cells, certain things within a cell. And it was taking people ages. And the solution was
literally, well, we'll just remap your keyboard, so that you press J and this weird string comes out.
And suddenly what you've got is people who are taking days at something being able to do it in,
less than an hour. And it's such a simple solution. And yeah, you could turn that into a business model.
But realistically, this is just, it's just an easy way of making somebody's life so much easier. And
it's not hard. Anyone can write that, right? It's not.
Right. On the other hand, I think I know some people who they did. One of the big problems is
people who don't take their medications, specifically if they're ill. I know some people who tried to
create a company. I don't know how I was doing. I've lost track of them. But that was take your meds.
So essentially people getting a text message when they should take their medication because
people don't take their medication. It tends to make the whole system right because things, you know,
suddenly what should be very cheap is super expensive because you then have to go in there
and make, you know, real.
Yeah. Do some kind of intervention. Yeah. So like schizophrenic stuff or medication or
depression medication. I feel like people take that stuff and then they're like, oh, I feel better now.
I'm better. I don't need my meds. Right. But maybe, you know, maybe it's because you're taking the
medication. As soon as you stop, you're like, oh, my gosh, it's all back to beginning.
It's often for like geriatric, well, geriatric, like old people who, you know, they're required
to take medication once every three hours. And it's so easy to forget. And as soon as you don't,
well, suddenly you haven't taken, I don't know, that medication and you're at risk of a heart attack.
Yeah, of course. Yeah. I guess if the frequency is a couple of hours, it's tricky. Yeah.
Yeah. Cool. So we've, you've got these NHS hack days, which sounds like a really good idea. I don't
know if we have that in the US. Maybe we do, but I've never heard of it. You know, I probably one of
these cool benefits of government healthcare. Interesting. So, so, you know, it's not all just
for profit. Like who wants to go help? I don't know, like your local HMO make more money or that
local health insurance company. Right. I'm not going to go do a hack day for any insurance company
whatsoever. Right. Unless it's just weird. Anyway, this is cool. So you guys have these
and you went there and, Opal was born out of it, huh? So yeah, Opal was born out of,
out of that by, by my, my wife, a colleague, like a couple of years before,
before I joined open healthcare. And then I was contracting. I was, I went to a couple of these
hack days and been to a couple of years in a row. And then I went to work for, went to an interview at
quite a sort of prestigious startup. it was quite as intense a process. Like, I don't know,
six hours of continuous interviews. And then in the last one, the founder of the company said,
where do you see yourself in 10 years? And I said, writing software for open source software for the
NHS. So then I turned down their offer and went to work for open healthcare. Cause I realized by going
through that process, that was actually what I wanted to do. So why not do it now?
It's pretty grand.
That's grand. So I think this is a good test. People should give themselves periodically,
right? The five year, the 10 year test, you know, in this case, it was where do you see yourself? Like
in the broad sense, but it could also be, you know, look at the people that are five or 10 years more
senior than you and your company. What do they do? Do you, do you want to do that? If you don't want to
be doing that, the time to like start finding a different path is now, right? Because that's,
that could be right where you're headed. I think that's a great motivation.
When you go into an interview and you see the people who are interviewing you,
the first thing you should think is, do I want to be these people? Do these people
seem happy with their lives and their life choices?
Yeah, that's really great. I totally agree with that. All right. So that's a pretty big goal. And
I think it's a very cool thing, but I also see it as challenging just as a career, right?
I want to go write open source software for NHS. How did you tie that back to the career in your
mind? Like, how are you going to pay the bills while doing that?
The business model is essentially quite clearly there. Like if you can create a good service,
medical software is big business. I don't see the open source as in any way a blocker to this.
I want to, like the NHS are paying us money. We're not doing this out of the goodness of our hearts.
the open source means that the quality of the software can be more rigorously tested,
that there's not so much of a contractual lock-in because one of the problems that you get, I was
talking to a hospital that will remain nameless and a lot of the medical data is with one system and
they want to shift to another system. And they said, how much to move it across? And they were told 10
million quid, 10 million pounds. Yeah. The hospital was like, we can't afford that.
So we just dumped the data and the sort of computer proprietor said, well, it'll be 10 million pounds to
delete the data. That's rough.
Yeah. Right. There's a bad system of contractual lock-ins. So by being open source,
we can provide great quality software, we can charge for great quality software, but if they
don't like us, they're not locked into us because anyone can look at the source code that we've
written and sort of take it over if necessary. Hopefully that's never happened so far and we'd
like to think it won't.
I think so. And you know, it's based on super popular stuff, right? Things that most people
who know Python could walk in and get up to speed on in a week or so, at least. And you know, Python
being the most popular language or at least contending not for that, that's a pretty solid
statement that people can just pick this up. So tell us what Opal is.
Opal is a web framework for building healthcare applications that store medical data about people.
Cool. So we have Django, we have Flask, we have Pyramid, we have Starlet, we have these other
frameworks. Why do we need Opal? What does it do in addition to just, you know, Django, you know,
create app or cookie cutter, Pyramid or Flask?
Yeah. So that's a super interesting question because in the levels, Opal is kind of, it's a domain
specific framework. So you have Django, Django is do anything on the web. So Django,
Django arrives on the scene. And I don't know if you're too young to remember this. But Django
arrives on the scene and suddenly you were able to say, well, I want to create a polls app. And
you know, I was able to do it in a lunch break. And I was able to do a week's work in a, in a
lunch break. And that's, that's amazing. And it revolutionized things, right? And then from
there, you don't have that too many sort of domain specific, I guess, blogging software is the,
is the most domain specific where you have software, which is a framework, which are,
I'm just going to build a blog. I'm going to do one thing. So you've taken, right?
Got something like Django and then you're super specialized on top of that.
Right. Like WordPress or ghost or something. I hadn't even really considered blogging,
blog frameworks, platforms as, you know, domain specific. But yeah, you're right. They,
they definitely are. And it makes a ton of sense, right? I'm just, you know,
thinking about what you get. So this is built on Django, Opal is. So it's not like
another framework in the sense of that it's trying to compete with those, but it's,
let's take Django and let's, let's take all the boilerplate junk that you have to write
to build something in the clinical domain, make that happen. And now get started, right?
What we can do is we can say, we know you're going to have patients. We know you're going to have
episodes of care. We know, yeah, we know you're probably going to have these bunch of clinical models.
And we can therefore make loads of assumptions, which means that we can scaffold things out quite
quickly. So we know that you're going to have a patient list page, patient detail pages of different
types of episodes of care. We know that you're going to want forms for, forms for, for example,
conditions for diagnoses that are going to hang off an episode of care. So we can say,
we can scaffold you up forms for the condition. We can scaffold you display templates. We can give
you a rest endpoint for an episode, which will give you all of the things which are hanging off that.
So you've got that for your treatment, your diagnosis, maybe your treatments, maybe your blood cultures,
maybe your lab tests. We can just do that super quickly because we know that's what the modeling
structure that you're going to want.
That's great. So you don't have to think about all those things. You just start using them. And these
are all classes. These are Django entities, right? In the Django ORM. But you could create ones that are
more specialized. You could create other ones that go in there, right? So it's, it sounds like a lot of
the core data models already put together and, and things like that, right?
We have sort of a specialized model called a sub record that we know that you, you can use, which we
know will have a relationship to a patient or relationship to an episode. And because we know
that model structure, we can automatically wire that into forms and stuff, as I said, but also into
search, into data extract. We don't, Opal doesn't enforce like a model structure. It offers this. And this,
uh, a lot of what these kinds of frameworks do is they, and what Opal tries to do is get you 80% of
the way there. You know, once you're there, once you've done, once you've started prototyping, you
might be like, Oh, I want to just use more sort of vanilla Django stuff. Opal doesn't stop any of that.
It just gives you a helping hand in what we think the right direction.
Yeah. I just that quick, quick boost. And even though this came out of those NHS hack
weeks, I suspect somebody could take this as the starting point for another one of those and really
bust out something pretty amazing, pretty quickly. It sounds like, cause it just puts all this stuff
together for you. So one of the things that these episodes, sub records, which are the Django models
do that. I don't know. It's kind of interesting to me is it creates a relationship between the
entities already, right? Which is pretty cool. But it also creates a JSON API for creating and updating and
searching them. It creates, make sure that the angular layer, we'll talk about angular in a little
bit, the angular front end layer knows about it. bunch of stuff like that, right? That's pretty cool.
Any modern develop web developer knows that you're probably going to want to have Django rest framework
endpoints for a Django app. So exactly right at Spox, it gives you those. It does some schema
description so that if you're looking for other developers to use to like programmatically read
your endpoints, you can give them that description and they'll have an understanding of
what data is going to be available. so yeah, I think, I think it's all right.
That's pretty sweet. So it comes with batteries included, but these batteries are more like
stethoscopes and tongue depressors. That's excellent. I'm stealing that. That's fine.
Feel free to steal it. It's all good. I'm sure there's better, better,
analogies in the health space, but that's a good start.
This portion of Talk Python to me is brought to you by Linode. Are you looking for hosting that's fast,
simple, and incredibly affordable? Well, look past that bookstore and check out Linode at
talkpython.fm/linode. That's L I N O D E plans start at just $5 a month for a dedicated server with a gig
of RAM. They have 10 data centers across the globe. So no matter where you are or where your users are,
there's a data center for you. Whether you want to run a Python web app, host a private
Git server, or just a file server, you'll get native SSDs on all the machines, a newly upgraded 200 gigabit
network, 24 seven friendly support, even on holidays and a seven day money back guarantee.
Need a little help with your infrastructure. They even offer professional services to help you with
architecture, migrations, and more. Do you want a dedicated server for free for the next four months?
Just visit talkpython.fm/linode. When I think of this project, it sounds cool. Like if I, as a primarily
web developer, when I'm writing code, when I'm thinking of like, how would I use this? Obviously,
I would go out and I would build some cool healthcare app if that was the domain I wanted to spend some
time on. But when you think about this project, who do you have in mind? Like, have you made this for
people like me? Have you made this for the IT folks inside the company? Have you made it for doctors?
Like, who do you have in mind using or who's ended up using Opal?
That's a nice question. So in reality, we use this ourselves. Obviously, we exist in a number of
major hospitals for sort of a whole bunch of teams. And I think that when building a framework, you know,
you need to, what is it? Eat your dog food? Yeah, we are the dog. And this is designed for other
dogs like us. So other developers being brought into hospitals or who already work in hospitals
to develop healthcare applications. That being said, doctors, as it turns out, incredibly smart,
technically minded individuals. And a number of them have picked up an experiment with Opal for their own
sort of side project and for projects for their hospitals. I'm not sure a doctor has ever released an
local application into a hospital. And maybe you'd want to give it a code review first.
It's going to need some refactoring. I'm not so sure about this. But you know, I think that's really
cool. And I do think that's one of the things that Python makes more possible for folks who are really
smart and technically minded like doctors to just say, you know, I have this problem. And it's got to be
frustrating to go to work, at least in the US, it's you never log into your computer, you log into like some
Citrix, remote desktop thing. And you know, it just there's probably all these frustrating like layers.
And they're just like, you know what, if I could just have this thing, it seems so easy.
And you know, they probably just, you know, start busting something out, right. And then they can bring
that in and be that proof that you talked about, like from the NHS hack days sort of example.
Exactly. They can just say, look, it's not that hard.
I have a funny story. I'll tell you real quick about a doctor and programming. I was at the doctor.
I don't remember why it was nothing major, just some random thing with the doctor.
Maybe 2010, something like that, quite a while ago. And the doctor said, what do you do?
So I'm a programmer. And I said, what language do you program at the time? I'm like, well,
programming this language called C#, which I was at the time.
And he says, pauses for a second. He looks at me. And I thought he was just trying to make small
talk. Right. So he could like, before he stabbed me with a needle or something, looks over, goes,
you excited about the new release of Visual Studio? I'm like, excuse me? He's like, yeah,
this new stuff they're doing is so great. I'm really, I'm like, are you a real doctor? Who are you?
Like, who gave you that robe? I'm not sure I want that.
Yeah. Did this make you trust him more or less? What's the,
both, both, but it's so interesting because you like at the time, I'm like, oh, sure.
They're surely they don't care. But the more I interact with doctors, the more I realize,
you know, yeah, for sure. They, they have these challenges and you can bring in programming
languages to solve those at some point, like the pressure gets too high. You're just like,
I'm going to write this website. That's going to solve this problem. I do see it as an extra
challenge in the healthcare space over, you know, some other, I said, say accounting or something,
right? And then maybe it kind of is not even the best counter example, but in healthcare,
you have to be a little more careful with your data and stuff. So you can't just like,
I just threw it on like a random server on the internet and it's easy now. Like,
well, maybe that's not going to fly.
To me, one of the interesting things about the medical space in relation to other space. So
as I say, I used to just sort of do some investment banking stuff.
what you have there and what you have in a lot of places, you have things like stocks,
stocks are essentially manmade inventions, right? And therefore they've already like a man's mind can
comprehend what they were and, or a person's mind can comprehend what they were and draw the
limitations around that. And there's, there are legal entity in that to describe. Whereas when you look
at modeling in a medical sense, it's such a, a broad, we're just ascribing concepts to real world
conditions. That means that modeling comes far, far fuzzier. Sort of when you're saying sort of like
obesity, somebody's dying of like drowning, well, nobody dies of drowning. They die of like an oxygen
deficit kind of thing. Right, right.
So when you're filling in your medical notes, what do you do? Well, you know, like, which I think
means and different doctors will put in different things because if you're a blood cancer specialist,
then your concepts of dying of this, I don't, okay, maybe I don't know that. Maybe I don't know blood
cancer for certain, but definitely when describing a blood cancer, describing a blood test, if you work
in microbiology, your description is going to be different from a doctor who was another specialist,
which I think is super interesting.
It is. And, you know, I think it really makes the modeling challenging, right? And we already talked
that there are some of the, the sub model, some episode, sub episode classes, like the Django model
classes that model these things, but they're coming from a certain perspective, right? Like one of the
things that you talked about on the, maybe on the tutorial, I can't remember where I saw this, but
to, you know, a cough, it could be a symptom of a condition or the cough itself could be a
condition. So if they come and say, Hey, I need you to treat me because I have a cough,
then that's probably the condition. But if they have a cold, then it's just a symptom, right?
So how do you record that in your database?
Which is it a symptom or a condition, right? These are, these are challenging.
I sat in a room with doctors having full blown arguments at each other about exactly this. And
it's kind of like, well, if you don't know, how do you expect us to know that?
Yeah. Well, that's the problem or the challenge of building something for a domain, especially if you're
not yourself a doctor or you're a specialist in that domain, it makes it harder to model stuff in that
domain as a programmer. But it's also the value, right?
That is one of the things that I will try to say, you know, the programmers, I, well, I've been a
programmer for 12 years now. I've been around the block. A doctor has had, what, at least five years
a university, probably two years after that, still sort of learning the ropes, you know,
they're going to be eight, nine years down the line. And so the, what Opal tries to do is trying to
create through, essentially the, in some levels, the Django sort of modeling, Django models is to kind of
create a bridge where two very, very complicated domains can kind of meet and discuss in a way that
they can understand each other. I guess it's that shared experience, right?
So maybe an interesting way to talk about, to give people a sense of what this is and how it works.
Maybe we could talk through a getting started story. So you have a tutorial on the website and it says,
as a doctor, you want to know what's going on with your patients under your care so you can treat them
effectively and whatnot. So you need some kind of app or something to manage that. Let's build that in,
in Opal, which is pretty interesting. So do you want to maybe just talk us through,
like this whole getting started story here? Opal does similar thing to, I guess, Django app and start
projects, but again, more specific for, for medical applications. So out of the box, we essentially
give you some core clinical models that we think are pretty good and you might like, and we give you some
reference data that you might want to change, but it's the kind of thing that you want loaded in this
table. So we give you a list of conditions that doctors have given us in the past and said,
these are the kind of conditions we want to record. We give you sort of basic sort of demographic lookup
lists. So again, you know, like gender, ethnicity, you might want to change them, but out of the box,
give me something sensible. When you run the create project, you get sensible defaults and it gives you a
patient list and episode detail page and a way of adding patients because we know from the domain
that these things that you're going to want. Yeah. And it feels very much like getting started with
Django itself. So the way you get Opal is you just pip install it. That's cool. All right. You just pip
install this or put it as a requirement. And then you say, Opal start project, and you give it a name,
very Django-esque. Go in there and go in that folder and you say, Python manage that py run server,
right? Like you could just replace Opal with Django. And so far you're on the same path, right?
I mean, that might just be for a good reason. Exactly. We've taken what Django, we think Django did
well and hopefully extended that. So yeah, exactly. So it gives you the Django settings, which are probably
going to be the ones you want. It gives you an S you like, you know, it sets you up with a S you like.
Right. So basically, if I'm a Django developer, it's super easy for me to drop in and get started with
Opal. I just have to learn the new batteries that you've added, right? And the conventions that you
follow. We've given you some sugar. But if you're a Django developer, it really shouldn't take you,
it shouldn't be too difficult to figure out what we're doing. And I will say, once, you know,
if you want, if you're a Django developer, you're like, I like what you've done with this,
but I'd like to do this in vanilla Django. We don't stop you from defining your own views and
doing what you like. How much of what Opal gives you in terms of this scaffolding business here,
how much of it is a, at the beginning of my project, one time only, or is there a way to
periodically add new entities and new views? Right. So maybe I have like, like I have demographics
and treatments and diagnosis and all that stuff comes out of the box, but then say like, oh,
I need a surgery and I'm going to add that. Is there a way to run like a command line option to,
to do all that magic to add it in? Or do I, am I kind of on my own once I started?
So you add in a carer model, for example, for a patient, for an episode, you add in your Django
model and then you run managed applied scaffold. What we'll do is we will create you a form template
and a display template. And then you have to go into your patient detail and which will already have
a list of similar sort of record panels as we call them. And you can just add in that,
but with care instead of what that gives you is a display template and a way of adding automatically
wires you in like a modal form. So you click add one and it would bring you up a modal form.
And then what we do is we look at a method called underscore is Singleton. We look at a property
called underscore is Singleton on model. And that tells us if it's a one to one model or a one to many
models. So obviously like demographics, you're only going to have one, but you're only going to have one
name, right? Well, it's not be true. You're only going to have one demographics model related to
a person, whereas you may have multiple treatments. And so that tells the record panel whether to allow,
let me add many treatments or just let me edit the single demographics model.
That is awesome because then you could just keep adding these Django models and then just rerun
scaffold and it does all the stuff for you, right? All the magic.
Exactly. So it just ellips your model and then creates your form, a whole bunch of point fields
off the back of that. We are different from vanilla Django. We use a template tag for our form fields
because under the covers, this is all, there's, there's a whole bunch of angular that's happening.
So we're not refreshing the page. We're bringing up a model. We're editing it. We're changing it.
We're saving it. Everything just working with the doctor the other day. And what was really lovely is
they changed one of the models and then they looked at form. And personally, I really like API design.
And when somebody like doesn't even need to look at the dots and they're like, oh, I just need to change
this to this. And you're like, that's grand. Yeah. My work here is done. Yeah. You know,
you build a good API when they're their first guess, their first intuition is exactly what you'd hope
they would do. Exactly. Super cool. So one of the things I saw in the tutorial that was pretty
interesting is you have these relationships like, you know, what problem or symptom did this person
have, and there's probably a big pre-filled list, like a dropdown select. You can pull down and choose,
you know, they've got a fever, their foot is broken, whatever their bone is broken.
But it's, it also allows you to type in free text. So you have this column type field type,
foreign key or free text. That was really interesting to me is that you guys came up with that,
right? That's not part of Django. Yeah, that's all our pattern. I've seen like different people in
different places, all of them having to roll their own sort of customized implementation of
exactly the same thing. It's such a common thing that I want to put in a sort of a foreign key
relationship or free text. And what this does is it does exactly that. It's a free text box,
you can type in whatever you like, but there'll be an auto complete bunch of options. And you can
select one of those and it'll save it as a relational, as a foreign key method. And one of the things
that's nice is that they, it also supports symptoms. So say you can have a cough or a sore throat or,
I don't know, a pain, pain throat. I don't know. Yeah. You kind of get the idea that quite often
there's two terms for the same thing, symptoms and what the doctors can do or what they can tell us to do
is say, wheezyness and breathlessness are the same thing. And it will reconcile those so that you have
a consistent view of what the patient might have if they both fit in.
Okay. That's a really cool feature. I love it. That's that's, I think that's great. And it seems
like it shows up really nicely in the UI. So let's talk about, you know, you mentioned Angular and whatnot,
we've obviously been talking about Django, but let's dig into some of the tech.
Want to tell us what's involved? What, how you built it?
We've got Django on the back end. And then at the moment, we've got AngularJS on the front end
and Bootstrap. A lot of these, as I say, it's, it's framework for people who come to Opal aren't
necessarily going to have a background with Opal and the technologies are very much well,
just stack overflow will answer my question. That's super easy for that. So yes, we've got
AngularJS and then there's a bunch of magic that wires things together for you. So as I say, there's
a schema that you can get out for particular for each of your models, which describes the model and
AngularJS consumes that and it uses that when constructing forms.
Does it talk back over Django rest framework?
Yeah. And then Angular, because we have the concept of form templates and display templates,
and they're all scaffolded out for you. We can make reasonable assumptions and Angular can,
ideally, you don't even have to like touch Angular that much, but you can. So we use a model for the
front end, which I haven't really used that much before. It's one that my colleague sort of did,
which is actually what I want is I want all of a patient. So whereas in previous projects I've worked
on, I'd be like, well, the patient, they want treatments, they want diagnoses, do separate
API endpoints for that. When you go for a patient or an episode, it's like using a DRF. I think they
like using a nested serializer. We don't use a nested serializer. So essentially, you get an episode,
then it serializes everything under it. So when you're doing front end code, you know what is
available without having to worry about, well, this loaded, this didn't load, which is really nice.
It's a lovely fact.
I see. So it like traverses the foreign key relationships and it creates a hierarchical
JSON response type of thing.
Exactly. Exactly.
Okay. And so we serialize everything for that episode in one go because experience is showing
that's what doctors want. And that makes it a lot easier in the front end to know that the model is
going to be similar to the back end.
It's worth just saying, you know what, we'll pay the extra price and we'll ship the episode
along with the patient and it's going to be fine because you don't have two ways to do it.
You can pre-fetch related all of the things and the number of database queries you're doing is
pretty efficient.
This portion of Talk Python to me is brought to you by the University of San Francisco.
Learn how to use Python to analyze the digital economy in the new master's in applied economics
at the University of San Francisco. Located at the epicenter of digital disruption,
USF is the ideal launching pad for the next phase of your career.
Their new STEM designated economics program doesn't just provide technical training in high demand
skills like machine learning, causal inference, experimental design, and econometrics.
It takes the next step, teaching you how to apply these techniques to understand the economics of
platforms, auctions, pricing, and competitive business strategy in the world of big data.
The program is open to beginner and to advanced coders looking to apply their skills in a new area.
Applications are now open for the fall 2020 classes.
To learn more and get an application fee waiver, go to talkpython.fm/usf.
That's talkpython.fm/usf.
Speaking of databases, it sounds like you're using Postgres.
Yeah, we use Postgres.
When you do the sort of tutorial app, vanilla, it gives you FDLite because if you're a hack day,
you don't necessarily want to teach people how to install Postgres onto their computer.
Yeah, SQLite's beautiful like that, right? You can just say you have basically a full database.
But you don't have to do anything. Can you make a file? All right, let's go with that. You know what I mean?
I love it.
Yeah, I do too.
I think it should be used more. A lot of the times when people are exchanging like CSBs in like big
app institutions, I'm kind of like, oh, why don't you just stick it in an FDLite database and ship an FDLite database?
Yeah, it's super great.
For sure.
So it sounds like it's a pretty good project in terms of how it's all put together, some of the technologies.
What's the deployment story look like? Is this, you got to make sure you set up Postgres, you set up Celery, you set up, I don't know, Microwiskey or G-Unicorn or whatever it is you're going to set up.
And then is it a bunch of steps or is there some pre-canned way that people can run a magic script and have the infrastructure?
So at the moment, we don't have that pre-canned script. I mean, we do for our own deployments in-house.
Sure.
Obviously all scripted up. But the reason why we haven't is because hospitals vary quite a lot in the sort of VPN technologies.
So what we tend to do is have boxes on the hospital sites that are running the software that sort of gets us around any sort of security issues.
And depending on the VPN, sometimes you can only log in on the VPN via a Windows machine doing this, the other, whereas others you can wire together with Ansible and do your deploy scripts with Ansible.
So sometimes you've got the fabric scripts, sometimes Ansible scripts. So we don't have that vanilla out of the box deployment scripts, which would be quite nice.
What I've been hearing a lot lately for setups like this is what we're going to do is use Docker.
I mean, I'm a fan of Docker, but I feel like that adds another layer of like, okay, you did have to know Python web frameworks and you have to know Postgres.
Well, now you kind of sort of have to know this, but you also have to know Docker.
You know what I mean? It's like, on one hand, it gets simpler. On the other, it like expands out the things you have to maintain and manage.
So I don't know. It's tricky.
No, I think that's great. I think we have been looking at that. I think I looked at it a while back and maybe I'm wrong. I could be wrong with my memory.
But I think that the version of Ubuntu that they were running it on was not going to casually allow us to run Docker on it.
Right.
But maybe, maybe that's exactly.
Yeah. Speaking more broadly, I mean, because this is healthcare, it has special constraints on where it can live.
Right. But if you were building this kind of thing for something that wasn't so regulated, it might be cool to build some sort of Kubernetes thing and you could just plug it into one of these managed Kubernetes clusters.
Yeah, that would be cool.
Right. Like that, that would be cool. That seems like a pretty easy way to say, look, you don't have to actually worry about running it.
You just get this service and you just jam it in there and you can scale it with these knobs. You're good.
Right. But when it's down to you running the clusters, we talk to clinicians a lot because we deal with a lot of sort of like new services.
And as I say, we're not the greatest judges of when we don't have a clinician's experience.
So we do a lot of like just roll up a hierarchy box with this branch, roll up a hierarchy as well through this branch, send them both over to the doctors and say, try these, play both of these.
But we haven't, we haven't branched out to Kubernetes, which is what the cool kids are using.
For now, anyway, you never know. You chose a JavaScript front end framework. And, you know, what is the lifetime half-life maybe of one of those things?
I mean, Angular has been going for a while, but we had Angular 1 and Angular 2. I feel like those are almost different things with different programming languages.
And that's a big decision, but you got to pick one, right? Like that's how it goes.
Well, I mean, we are, we are, we're now rolling, we're, we're now working on Opal 1. So previously been on zero point star releases.
And as such, we are aiming to move off the, the AngularJS because it's end of life.
And we are currently doing, we're essentially practicing experimenting with Vue, React, just, you know, to, it's just progressively building off sort of,
the Angular forms with some, with some extra sugar.
That's cool.
It's the whole experimenting with those. I've heard you like Vue. I'm a big fan of Vue.
Yeah.
So I have a version of Opal that just runs Vue, but it's making sure that what we've got is easy and simple for the developer.
And, you know, I can't make it, I, just because I like Vue, do well, have I experimented enough with React? It's tricky.
And I mean, I think more of the problem is shipping it.
So, you know, now what we've got at the moment and what's quite nice is static assets.
You declare your static assets, the file names into, into either plugins or into an application and Django compressor just does it all for you.
Whereas now, if you're looking at something like Vue or React commonly, you need to, you don't need to, but Webpack is kind of the, the assumed approach.
And then you've got the Django webpack loader, but the Django webpack loader, based on what I've currently seen, I don't tend to be an expert at this, is doesn't necessarily load from packages.
So, for example, you pit installed Opal, or you don't, if you want the static files, which are coming through with that, the Django webpack loader won't actually pick those up.
So then you have to say, well, so do we then store the static files on NPM?
And so we then put, you pip install Opal and through some magic, we'll bring in the static files from NPM.
But then obviously then you're supporting two different packages and you need to concentrate that.
It's a super interesting problem.
And I'm quite enjoying playing with it.
It sounds challenging.
It sounds a little bit, I don't know, in the UK, if you know the game Whack-A-Mole.
It's like this arcade game where you be, you know, it reminds me of that, right?
Like, I'm going to, bam, I solved this problem.
Oh, it pops up over there.
Whack, I solved that problem.
Now it's back here.
Like, you know, you squeeze on one side and it pops out the other.
And, you know, it's challenging, right?
It seems challenging.
But yeah, to be honest, I don't know.
Different programmers find different problems interesting.
I do find this interesting.
I do sometimes think it could all be simpler.
But that is probably my own ignorance.
Yeah, I feel like JavaScript went from being like, oh, it's the most easy, simple little thing to, oh, this is, there's a lot of stuff going on here.
I'm not really sure why, how this is happening here.
Yeah, well, it's like, oh, I'll just run NPM install.
Suddenly my computer gets hot.
Yeah.
Exactly.
Yeah, interesting.
Okay, well, I'm a big fan of you.
I definitely think it's special.
I like that as well.
Now, let's see.
Let me ask you a couple other questions.
We're getting a little towards the end of the show here.
One thing I guess it's interesting to talk about, just real briefly, is Opal is open source.
Go to GitHub.
I can get it, do whatever I want, right?
I can pip install it.
Yeah.
But you work at Open Healthcare UK, which is that like a boutique app shop for the healthcare industry?
Or how would you describe it?
The way the healthcare in hospitals commonly works is that what you have is the productization,
if that's a word, is massive, large-scale EPI are pumped in and it aims to be a data repository
for all teams in the hospital doing all things.
It's like the SAP of hospitals.
It's going to do everything.
Just install this and it'll be fine, right?
Exactly.
Okay.
And what you find is that it does a pretty good job, but for, it does 80%, but for the
extra 20%, what you've got is Word docs flying around, Excel spreadsheet, the occasional access
database, or good old-fashioned pen and paper.
Yeah.
And sometimes this 20% is pretty darn useful.
So we have, what we do is we fix up that 20%.
So you're a, we do microbiology, for example, we do some of that sort of stuff, which is
sort of teams which specialize in blood cultures.
We go in there and we're like, and we talk to the doctors and we get their requirements and
we tailor stuff as sort of kind of specific to them.
And yeah, we cover that 20%.
That's cool.
So basically the role of Opal is this thing that you guys have built, it'll let you quickly,
it'll, you know, supercharge your creation of these apps to cover that 20% that you talk
about, but it's also awesome that it's open source and other people can take it and run
with it.
Is that right?
That's right.
That's exactly right.
This is not that much of a specific problem.
This is a general problem.
I think worldwide, I don't think, I don't think in the States they've kind of got a magical
EPR that fixes all problems either, right?
No, no, no, no, of course not.
Yeah.
Cool.
So it seems like a solid blend of here's this open source thing that people can work on and
they can use, but is also there to support your business.
And, you know, one of the things I feel like just doesn't seem to work really well is the
PayPal donate button on open source projects, right?
It's just my experience of hearing folks who seem like they have pretty popular projects
is like, you know, it's definitely not a career at that point.
There's got to be something else.
And this seems like a really nice synergy around that.
So that's cool.
Our motivation for open source isn't.
It's open source because healthcare applications deserve the rigor that being open source allows
you to have and the inspection.
Open source is kind of like a function for you should buy our software because it's open source
and therefore hopefully you can trust it more.
And yeah, that's the sales feel, I guess.
It's the antidote to that 10 million quid problem.
10 million to convert and 10 million to delete.
Which one do you prefer?
Exactly.
Well, I guess on that, are you looking for contributors to this project?
You know, are there restrictions that people want to take it and run with it and do something else?
I'll sort of, what we would like is, as I say, we're moving front-end framework.
I don't think, I think everyone has, I think every developer right now probably has experience
between moving between different jobs for front-end framework.
We'd love some opinions on that.
We'd love anyone to come and have a look.
Come and have a look at the GitHub repo, offer suggestions, any breaks in docs, any breaks in
anything really.
That would be super interesting.
Also, you know, we've come at this from having years of experience with building healthcare
applications in the UK.
Well, does that necessarily create an international, something that's internationally applicable?
Sure.
At the moment, we have NHS number as a field on a model.
That will not be happening soon.
We are going to move off that.
But that kind of thing, you know, this should be a global solution to a global problem, not
a UK solution.
Congratulations on this project, Fred.
It looks really useful for folks out there.
Thank you very much.
It's been quite short to you.
It's quite a little grand.
Yeah.
Now, before you get out of here, though, I've got the two final questions I've got to ask
you.
So if you're going to work on Opal and write some code over there, what editor do you use?
I use the Vim plugin on VS Code, which is interesting.
I occasionally go back into pure Vim.
Before VS Code, I used Sublime.
I used IntelliJ when I was a Java programmer or using the Vim plugin.
Vim plugin.
And so I think I feel like I've spent my life doing this sort of weird hybrid of helpful
Vim versus a more integrated environment.
A constant pool.
Yeah.
But VS Code sounds like a good one these days.
It's got a lot of momentum for sure.
And then notable PyPI baggage?
I really like cache properties in Django, which are, if you've never used them, essentially
it's an annotation that says, here's a method.
Store the results of this method on the object.
And then whenever I call this method, first time I call it, calculate it and return the
answer.
Subsequently, store the results of the method.
I just think it's a beautiful pattern.
It's been something that's been discussed as part of core Python for some time.
Danny Greenfield, I think.
Hi, Danny.
He has a package on PyPy that does this because it's such a common function.
And then in Python 3.8, just a few weeks ago, we now have functools cache property.
So it's been moved into core.
So I was hoping to have functools.cache property as my notable package, which is potentially
cheating because part of the core library.
But it's super useful.
It's new enough, right?
It just got shipped.
I think that's cool.
I think that's one of the really easy ways to speed up things.
The only challenge with that is you have to be careful on what cache invalidation means,
right?
That can be challenging to deal whenever you're doing caching.
And if you look at the pet, there's a long discussion about it.
I can imagine.
But, you know, it can just dramatically, it can just completely change the way the performance
looks, right?
So it's so easy to do those types of things.
Pretty cool.
Good one.
All right.
Final call to action.
People want to get started with Opal.
What do they do?
Pick and install it.
Take a look at the docs.
We've kind of covered them a little bit today.
I think they're pretty good.
So pick and install it.
Go through the tutorial and let us know what you think.
The code is all at openhealthcare.com on GitHub.
GitHub.com.
So, yeah, you can go and just browse the code as well.
Sounds good.
Thanks for being on the show.
It was great to talk with you.
Great, Michael.
Thanks very much.
Yeah, bye.
This has been another episode of Talk Python to Me.
Our guest on this episode was Fred Kingham, and it's been brought to you by Linode and the
University of San Francisco.
Linode is your go-to hosting for whatever you're building with Python.
Get four months free at talkpython.fm/linode.
That's L-I-N-O-D-E.
Learn how to use Python to analyze the digital economy in the Masters of Applied Economics at
the University of San Francisco.
Just go to talkpython.fm/USF to find out more.
Want to level up your Python?
If you're just getting started, try my Python Jumpstart by Building 10 Apps course.
Or if you're looking for something more advanced, check out our new async course that digs into
all the different types of async programming you can do in Python.
And of course, if you're interested in more than one of these, be sure to check out our
Everything Bundle.
It's like a subscription that never expires.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the
direct RSS feed at /rss on talkpython.fm.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
Bye.
Thank you.