Thursday morning, Wayne, Karen, and I went down to the clinic in Arequipa to discuss OpenMRS, FrontlineSMS, and MobilizeMRS with Lilia, the director of the clinic, and Maris, the assistant director of the clinic. There were a few goals to the meeting: understand the rudimentary electronic medical records system (EMR or MRS) in place now, assess the pros and cons of that system vs. OpenMRS, and discuss the possibility of running a clinic efficiency experiment with FrontlineSMS. We got through the first two agenda items pretty well but, being on Peruvian time, didn’t make it very far into the third.
Brain and note taking dump ahead.
The clinic has an EMR at the moment which is very limited. It was developed by a local programmer they still have good relations with and, every time they want expanded functionality, they just ask he (or she) to build it. Furthermore, the clinic staff has been talking over the last year about different ways to expand the tools. At the moment, it captures data about the patient, vital signs, and has a free text area for diagnoses. Continuing development on this software will require significant money, of course, which is why OpenMRS is probably a better long term option. Writing software for a pretty common use case doesn’t make much sense when there are customizable open source options available. Thanks to a relatively fast internet connection today, I was able to upload a HD walkthrough of their current EMR:
Tour of the clinic’s custom EMR from Daniel Bachhuber on Vimeo.
One fairly significant problem we faced Thursday morning, however, was trying to convince the clinic staff of the merits of OpenMRS without a full featured online demo or video tutorials. I personally haven’t experimented with the software very much, nor do I know all of the useful components of a medical records system, so I couldn’t necessarily sell the software with my salesmanship.
Wayne, being proactive, took the conversation from step zero so that Lilia and Maris would be able to help assess the merits and demerits of their current system:
Basic needs of a Medical Records System from Daniel Bachhuber on Vimeo.
According to the doctor, the basic needs of a medical records system are three-fold:
- Documentation – an EMR should have the ability to take notes and capture information on labs, Rx, Dx imaging, etc. Most importantly, this information should be searchable.
- Networking – an EMR should lend accessible communication, both internally (within the clinic) and externally.
- Decision support – an EMR should be intelligent, and assist the clinic staff in identifying high-risk patients, etc.
Once we had these criteria established, we started talking about the pros and cons of using their current system.
The pros of their system are:
- Easy implementation – the software is already installed on the computer and they know how to use it.
- Design specific to clinic – they can choose how they want the software to operate because they direct the development of it.
- Know[n] commodity – they know what they’re dealing with.
- Personal sw. provider – the developer is local and can come to the clinic to provide support, etc.
- Economically speaking + impact – Cheap for what it does.
The cons of their system are:
- Design specific – the design of the software is tied very much to the needs of their clinic today, and not five years in the future.
- Expandability – uncertain as to how difficult it is to extend the system.
- $ for upgrades – have to pay to have the developer build every single upgrade. Also, only the developer knows how to build or maintain the system.
- Don’t really know “OpenMRS” – don’t have the proper education materials to illustrate the power and flexibility of OpenMRS.
The unfortunate thing is that their current system doesn’t match up to the needs of an EMR very well. As it stands, it’s not much more than a data storage tool. They use it to house basic information about the patient, symptoms, and diagnosis, but it isn’t very useful as a tool to manipulate the information. On top of that, the networking support (connecting computers in the reception with those in the doctor’s rooms and farmacia), has yet to be built and decision support is cost ineffective.
The clinic is interested in OpenMRS, however. On Monday or Tuesday, Wayne will be showing Lilia and Maris a demonstration of the EMR he uses back in the States. This will ideally convince them of the practicality of having a robust EMR. We’d also like to get them to a clinic in Peru that has a working demo of OpenMRS soon. If this proves feasible, then we might be able to send the programmer they have to an implementer’s training with PIH.
A thought on bringing the programmer into the fold: this might actually be an economic enterprise for him or her. My thinking is that there are a number of clinics in Arequipa still using paper records, so if the clinic HBI works with becomes a local model for using OpenMRS, then that might get the other clinics interested in medical records and incentivize the developer to get to know OpenMRS better.
In the interim, though, the clinic will still put a bit more money into the system they already have.
On the note of SMS, we discussed the possibility of how mobile might be useful to increase clinic efficiency:
Day seven, Arequipa from Daniel Bachhuber on Vimeo.
The idea wasn’t very well received, though, because the assumption is that the demographic that the clinic serves most likely will not have cell phones, and the clinic staff couldn’t really understand how the technology could be useful. Anecdotally, however, a doctor said the penetration of mobiles in this market is near or over 90%, a statistic which doesn’t seem too unrealistic to me. Furthermore, I think that mobiles could play a significant role in improving the efficiency of the clinic.
We’ve got an experiment cooking too. Building upon the pediatric idea briefly outlined in my previous post, we’d like to have a control group, an experimental group which receives a reminder for their appointment, and another experiment where the group receives a unique code for a discount on their appointment. In preparation, the clinic will start collecting cellphone numbers at registration. Ideally, this experiment will be later this spring or early in the summer.
One last thought on efficiency: we’d also like to run a two week experiment (probably in February) where patients receive a time-stamp upon checking in to the clinic, and another one when the doctor takes them for their appointment. I think mobile could a tremendous impact on the clinic’s ability to efficiently deliver healthcare (the concept of being on-time for appointments is nearly zero), but baseline numbers will be really important to calculate impact.
