Guest post from “the field”

One cool program here at IHME is the field placements for our Post-Bachelors Fellows. This is a roughly 6 week stint during the summer of their second year here where they travel from Seattle to some distant place, to see where the numbers we’ve been crunching come from. Kyle Foreman is in Sri Lanka doing this now, and here is a guest post he’s written about an ICT4D challenge he’s seeing that he wants your ideas on:

I’m spending this summer in Sri Lanka working with the Ministry of Health and the community health department of the University of Peradeniya, observing how Sri Lanka’s medical record keeping and vital statistics system works. They’d like for me to make some suggestions on how it could be improved, so I was hoping to get some feedback on how to make this work.

Here’s the problem: keeping track of something as simple as the number of people who die each year is very difficult here. Patient records are kept at each hospital, then they are tabulated and sent to a regional office, then tabulated at a district office, ad nauseam, until they finally reach the national level. It takes literally years (they just finished the 2006 returns), is full of errors (because they do it all by hand), and is very incomplete (because every step along the way there’s further tabulation which strips away valuable data). They thus have difficulty identifying problems (especially outbreaks), targeting resources, and assessing the outcomes of their efforts.

Yet in every hospital I’ve been to, even the most remote, there’s a computer. I asked the MoH why they don’t use an electronic database for their records. It seems that even though most hospitals have internet access, they don’t want to implement something that not all hospitals can use. It’s smart for them to keep everything standardized, but I’ll bet there’s a way to make a system that’ll work across the board.

My first source of inspiration was Google Gears (which I guess is now being subsumed by Google’s HTML5 frameworks?). I use it all the time to compose messages in Gmail on the bus and then send them opportunistically when I find some wifi. The basic technology there – an application that uses a remote database when it’s accessible and a local database when it’s not – sounds exactly like what they need here.

But how to sync those local databases with the primary server where they don’t have wifi? Well, one thing that really surprised me here is their great cellular broadband coverage; I’ve yet to find a place where the 3G usb modem I purchased can’t find at least some signal (take that, ATT!). They’re too expensive for each hospital to have one, but what if each province had a couple that could be shared amongst the hospitals? Even if each hospital had access to a modem just once or twice a year, that’d be enough for them to sync the database and get national results sooner than 4 years after the fact.

Or maybe just add a feature to save the database to disk and the hospitals without internet can mail them in to be synced at the provincial registrar? And should there be paper backups that can easily be scanned in for hospitals with no computer (or in case their one PC fails)? Am I overthinking this – are bubblesheets like the SAT the best way?

My first thought is that moving from paper to computers is a great idea, and this sounds like a nice application area for the new noSQL databases that are designed to be “eventually consistent”. But my second thought is that I’m always making things too complicated, so I should think about it more before choosing precisely which new gadget is needed.


Filed under global health

11 responses to “Guest post from “the field”

  1. Mugizi

    I immediately thought of my Gmail app on my blackberry which allows me to delete and archive messages even when I don’t have internet access and presumably uses some kind of cache as described by Kyle.

    But I definitely agree that the best solution will probably be something relatively simple.

  2. kjforeman

    One big advantage here that I forgot to mention – they are already doing a great job of doing this record keeping at both the hospitals and the Ministry of Health field offices. It’s just that it is difficult to then collect all those records together and analyze them. So the habit of recording this information already exists, which is the hardest part of getting a program like this to work.

  3. ramiro

    hi there,
    what about some mobile application where each hospital sends an sms to a specific number, in a some sort of standardized way. maybe one could adjust, for example frontline sms, to do similar things. Frontlinesms has some sort of forms application that can be put on java enabled phones.
    or a very simple approach as you mentioned a normal xls-sheet and then burn it on cd and send it per post. what kind of data do they collect about the dead people? name, area, cause of death?

  4. @kjforeman: Based on your big advantage mentioned above, I think you should be considering ways to add to the already working system instead of making any changes that risk undoing the slow but successful system already in place.

  5. kjforeman

    Hello all

    Thanks for the input! An addendum:

    Today I met with the director of the Medical Statistics Unit. Among the many things I learned from her, the most surprising was that the MoH is currently working on a computerized system for death registrations. It sounds like it’ll be a simple Access or web database based system, though they’re still in the planning phase.

    This is similar to another instance of two groups working towards similar goals without realizing it that I encountered today: The MoH gets reports on in-hospital deaths every quarter, and they require every hospital to code those deaths to (a condensed version of) ICD10.

    The Registrar General gets death certificates from these same hospitals, but they only get a description of the cause of death; they then spend countless man hours (they said it often requires weekends or late nights, because the work days are spent granting marriage and birth certificates) coding those descriptions to ICD10.

    But the hospitals have already done that part for them, they just didn’t know it! But because the MoH and the Registrar are on separate campuses and seldom cross paths, they didn’t realize how much one could easily help the other.

  6. ramiro

    hi there,
    another very easy way of sharing data would be to get user accounts for dropbox. then they could share and synchronize their different tables automatically the moment they go online. works of course only for the ones that have a computer system.

  7. @kforeman: woah! is that a recent discovery? maybe the registrar general can send people around to collect the data, now that they have freed up all the resources they were devoting to recoding them!

    @ramiro: i think any solution has to be really streamlined to work like Mugizi
    concludes (although Kyle has a better sense than I of what is simple/streamlined for this community). Maybe an interface on top of dropbox, or just a really good directory structure to avoid the difficulties of synchronizing, could do it.

  8. kjforeman

    I love Dropbox, great idea! But I think Abraham is right in that there’d have to be something built on top of it. There’s a wide continuum of computer familiarity here. Some people caught on to an R seminar I taught right away and some are extremely proficient with ACME (which takes a lot of tinkering to get right). But others have little to no experience with computers, so they’d need something that automated as much of the experience as possible.

    And yes, it wasn’t until yesterday when I showed the people in the Registrar General’s office the forms I had gotten from the hospitals that they saw how much effort was being duplicated!

  9. David Hill

    Hello all,

    Wow, does this problem sound familiar.

    I’m one of the leads on which is the newly open-sourced base of the ICT4D solution for

    VillageReach works on health logistics management, with a first application on vaccines in Mozambique. One of the fundamental tech challenges is similar: collect and distribute long form data, from some places that were online, some off, but most of them both — occasionally and unreliably connected. Further, MZ had a similar policy that the solution had to work everywhere.

    For this part of the problem, our specific solution was essentially the HTML5 version of Gears. We use HTML5 manifest-based caching, local data store, and jquery libs to make a browser-based app that works offline. They enter dozens of multipage records at a time, offline, in Firefox, on a cheap netbook. When they can get the netbook online, they can upload all the data at once to our Rails web app, and get back updated reports and any updates to the local code. Generally, they’re planning on doing that once a month.

    Note that “online” is a very low bar: the app just needs to ajax transfer a few hundred Kb. No human browsing needed. Thus, 2G cell coverage is fine, and we also provided cheap prepaid USB cell modems. 2G coverage is surprisingly wide.

    This is part of a bigger strategy, of accepting data from a variety of sources. We currently have proofs of concept for accepting SMS and Android ODK xforms, alongside the online & offline app. But the offline browser app seems the most applicable here.

    In fact, it seems likely a customization of oLMIS might do the trick for them. Feel free to email me to discuss more! gmail address: hungrything

  10. David Hill

    @abraham: your instinct to work with their existing system is a very good one, and one we used in Mozambique. It eases acceptance and improves robustness. Moreover, the developing world is littered with the corpses of well-intentioned pilot projects, particularly tech efforts. Their systems need a clear fallback for when the tech fails, or international funding gets cut, or politics & bureaucracy squashes a program.

  11. David: I’m so glad you found our discussion. I think that a solution which joins forces with an existing open-source project has a huge advantage over one which starts anew.