On August 24th, Rich Bowen posted this interview in his SourceForge blog The Anvil Podcast. Rich has kindly given Open Health News permission to reprint this interview. The original interview can be found here.
Rich: Several weeks ago I went to the O’Reilly Open Source Convention in Portland, Oregon. The OpenMRS project was represented there by a number of the team members, and I was able to have a few informal conversations with them. After I got back home, I conducted an interview with Ben Wolfe, who actually wasn’t at the conference, but he talked to me about what the OpenMRS project does, and who is using it in the world, and where it’s going in the future. We also talked a little bit about their Google Summer of Code students. Here’s my conversation with Ben.
If you’d like to have your project featured on the SourceForge podcast, just drop me a note and we’ll schedule something.
If the embedded audio player below doesn’t work for you, you can download the audio in mp3 or ogg formats. You can subscribe to this, and future podcasts, in iTunes or elsewhere, at http://feeds.feedburner.com/sourceforge/podcasts, and it’s also listed in the iTunes store.
Rich: Tell me about OpenMRS. Tell me how it got started, and what your involvement is.
Ben: The idea for OpenMRS was hatched eight year ago … eight or more years ago. Burke Mamlin and and Paul Biondich went over to Kenya and they were tasked with helping fix an EMR that an installation was using there. The term “EMR” is used very loosely – it was just an Access database. But they had 10,000 patients, and so they wanted to be able to keep track of them and do various informatics types of queries and reports and all that. Burke and Paul realized that they wouldn’t be able to just fix what they had, so they started working on a data model for a complete system. And that’s the core of OpenMRS – the data model and how well things are structured to allow any kind of diseases, or data input, really.
About the same time, Hamish Fraser at Partners In Health, was realizing that the system that they were using was going to need an overhaul. Their system was actually pretty complex. It was just spaghetti code that was all over the place, so they wanted a clean start. Mutual friends got Hamish, Burke, and Paul together, and they started the collaboration that is OpenMRS. I came on board less than a year later as the first developer. And so I’ve been with OpenMRS since the beginning.
Rich: Are you actually from Kenya?
Ben: I’m not from Kenya. My dad was born there. My parents grew up there as missionary kids. I’ve gone over there a couple times a year since I started. I spent most of last year over in Kenya, because we’re adopting a little Kenyan girl, so that process is long and involved.
Rich: I grew up in Nairobi, myself. The guys that I talked to at OSCON told me that the project had strong ties to Kenya. Where else is OpenMRS being used?
Ben: OpenMRS is used in 72 different countries that we know about. Those are just from various surveys and different download stats that we keep. We don’t actually know the full extent because we don’t have any tracking software. And it’s kind of the Firefox model, where people download it and install it and customize it and use it, and the only time we hear from them is if they have a problem. We know of some of the bigger implementations in South Africa, Rwanda, India. There’s some in Central America. I know of only one in Southeast Asia area, I think it’s in Vietnam.
There’s a few in the US, but they’re typically these smaller clinics that operate kind of like a developing world clinic, which is what OpenMRS … we try to hit that outpatient clinic that’s able to help patients and help the managers write reports.
There’s a big push right now to make OpenMRS a nationwide system in Rwanda and the Gambia, and … there’s one other country … they haven’t actually come to us for help but we just heard through the grapevine that they want to do that. There’s a pretty wide footprint that we cover. And it’s always fun to hear from people that I don’t’ know that OpenMRS is this big player in the medical records space whereas we have no marketing budget, or any kind of advertising that we do, it’s just kind of spreads.
Rich: Tell us what the software does. Give us an overview of the functionality and how people are using it in the world.
Ben: OpenMRS was written as a patient-based medical records system. Our initial goal wasn’t supply hospitals with a full system where they could do scheduling and billing and insurance and all that stuff. It’s to improve patient care. And the way to do that is through getting the data back to physicians. If the physician sees that there’s value in the system, he’s going to keep using it. So, getting the physician to enter data, and then he see that again, and see the alerts on patients, or reminders … those pieces of information are huge and get the physician to keep using it.
We can convince the actual organizations to start using it by nice easy reports they can get out of OpenMRS. That makes everybody’s life easier. Under the hood, OpenMRS stores all the data in a very coded way. Or, at least, pushes people towards doing it in a coded way, so that doing those reports, doing reminders, those kind of things are very easy to write because things are stored with numbers and IDs instead of free text that has to be searched.
OpenMRS is a modular architecture. We can facilitate new features that we don’t quite agree with – something that wouldn’t get into the core of OpenMRS. So people have come along and said, well, we really need to do billing, so we’ll write a billing module. We need to connect with this insurance company, so we’ll write an insurance company module.
And there’s a big push now to get OpenMRS into regional hospitals. So, in Rwanda, and India, there are large development teams that are writing different modules to do the workflow within a hospital. That’s pretty cool to see. Groups that are outside of our core team doing their thing and customizing OpenMRS to their needs.
Rich: Are those modules contributed back so that they’re available to other end users?
Ben: A lot of them are. Some of the ones that are contributed back aren’t immediately usable in another country because they’ve coded it in a way that is specific to their workflow. As much as we can, if we can get a word in early in development, we’ll encourage people to write it in a general way so that they can either collaborate with developers in another country, or that they can share it and somebody can easily use it and build upon what they’ve done. It’s unfortunate … what we’ve found is writing something in a general way as opposed to just a quick hack to get your specific use case done usually about doubles the amount of development time.
There’s use case gathering, and designing and whatnot, that will go into the development of something generic and that adds a lot of time. When teams are able to invest the extra time to make it generic, they will, but the majority don’t have that luxury. An implementation is always running tight on time and need to have a solution yesterday.
Rich: OpenMRS is an Open Source software project obviously, but is there also an organization that is behind this, driving it?
Ben: Only recently. For the longest time, we just had our parent organizations – the Regenstrief Institute and Partners in Health, and Columbia University, and Kwazulu-Natal University in South Africa. But last year, we started making an OpenMRS Inc., a foundation that’s able to be the non-profit behind the software.
Rich: And where does funding for that come from?
Ben: We’re funded by grants from the larger funding organizations, like the WHO, CDC, IDRC up in Canada … They’ll fund us for either smaller projects that typically would be … go to this country, and do this thing, write this feature for this country. And we can do it in half the time, by writing it on the OpenMRS platform, and then the other half the time, we write general features and further OpenMRS in its general features. But the way funding and granting works, it’s kind of a behind-the-scenes thing.
Only recently did some of the granting organizations realize that there is power in the platform, and that all of the different implementations that are using OpenMRS, that they are funding, would actually do better by some of their money coming directly to the OpenMRS organization to make the platform more robust and stronger, instead of just funding somebody to go and install OpenMRS and use it.
So we’re not funded by actually doing implementations. We have no stake in a hospital somewhere. We let the community drive those implementations. The universities or consultants will go and actually do the work of installing it and making sure it’s running. There’s a thousand things you have to worry about when you’re running a clinic, that we’d need a much larger organization if OpenMRS was going to do that.
Rich: I was at OSCON [a few weeks ago] and I met some of your colleagues there, and we were attending an evening session on humanitarian open source software. Are you in touch with a larger network of organizations that do this kind of humanitarian non-profit software purely in human interest situations like this?
Ben: A fair number of them. We have a regular call which I think they’ve just labelled the HFOSS call, with a number of groups – I’m not even sure who all is on it – but I’ve joined when I have knowledge on the topic to add, and it’s groups like MIFOS that do microfunding, there’s another lab information software, there’s logistics software, there’s a few different ones that are larger in the space and have knowledge to provide and there’s a bunch of groups that come just to glean the knowledge that we have and ask questions and get answers. It is a small community. There’s definitely not as many groups doing humanitarian software as there should be.
Rich: One of the things that was mentioned at that session was the difficulty in finding volunteer developers to work on these projects. One of the things that was cited in that is that, typically, in Open Source, people work on stuff that interests them, that’s for their own use, that scratches an itch, as the saying goes. And that in HFOSS, you’re working on software that you’ll probably never use yourself. If people were interested in getting involved in software for the public good, software for the benefit of people that they might not even meet, where could they plug in? Do you have specific tasks that maybe people could plug into?
Ben: We actually get a fair number of volunteers that will stumble across the project and just want to help. I talk with a few people that say that they write software during the day that helps a furniture manufacturer make more money, and so when they go home they want to actually use their skills for something that will help other people. And so we get those kind of people.
There’s a few that are developing world programmers that see that it’s used in their country, and they say, that’s great, we think this is great software, and want to add to it. So having that humanitarian bent really gives us an advantage over some random library in Linux, because I very much agree that if you’re not using the software, then you’re probably not going to want to program for it, but because we’re doing good in the world, developers will see that, and say, that’s great, I want to provide some help for that.
I think the Summer of Code is a good example of this. I don’t know if you’re familiar with what Google does every year. And when they list out the hundred and forty some projects, a lot of the applicants for that are from overseas. 75, 80% or more are from overseas, because the stipend for the summer is much larger than they would make. And when they see our project, and see that we’re working in their country, we get a lot of applications. We’ve been blessed by Google because we get a lot of applications to our project, that we’re able to have more students, as compared to some other Open Source project, that might not be working for the common good, or in a developing country.
Rich: What are your Summer of Code students working on this summer?
Ben: I think we have sixteen students this year. Most of them are working on modules. OpenMRS – again, I’ll compare it to Firefox. We have pluggable modules that people can write that will modify any part of the system. So, at a clinic that wants to add a page to manage their thingmajig inventory doesn’t need to come to us and say, hey, I think this is a great feature, you should put it in here. They can just write a module and install it in their system, and be done with it.
We’ve found that the best way and the fastest way to get things written and tested and get it into the hands of implementers is to put it into a module. So we try to put all students on a module if we can. Most of them are doing that. They’re writing things like, the ability to customize a patient summary – the one-page abstract that a doctor sees.
My student is working on an HTML5 type of canvas that will allow a doctor at point of care to draw what he’s seeing. Maybe there’s a lesion on the hand, and he needs to mark where that is, so he’s able to actually draw that out right there on that form. This year’s crop is actually really good. I’m impressed with all the students so far. We require that they do a presentation at midterm, on one of our weekly developer calls, and they have to present what they’ve done so far. Almost all of them have presented something and they are almost done with their task. And it looks to be almost immediately usable by implementation.
Rich: Thanks a lot for taking the time to talk to me.