Introducing TimmyCare: An Electronic Medical Records System (Part I)

Introducing TimmyCare: An Electronic Medical Records System (Part I)
April 22, 2013 Callie Daniels-Howell

By Muz Ahmed

Muz Ahmed was working as a software engineer at Microsoft in Seattle when he caught the travel bug and wanted to get away (temporarily) to experience other places and cultures. In November 2012, he traveled to Tena, Ecuador with the Microsoft Medical Team and decided to stay! For nearly 6 months he has been working as a long-term volunteer in the Amazon Basin, combining his passions for health and technology to help revolutionize Timmy’s work via an electronic medical record system. This is Part 1 of a 3 Part Series about TimmyCare.


Abstract

TimmyCare is a web-based EMR developed in-house for Timmy Global Health. It’s truly amazing, and best of all, it requires ZERO paper. Paper is the enemy. If TimmyCare was a person, it would be a vegan. It would have dreadlocks, and eat only broccoli (that it planted itself). It would plant trees in its spare time and it would also run for president and win…But then turn the job down because it wasn’t involved enough. It would also eat lots of avocados.

Inception

TimmyCare’s inception began during a medical trip in November 2011 that took a group of doctors and a team of volunteers from Microsoft (Seattle, WA) to Tena, Ecuador. Upon observing how the clinic was run, a group of the volunteers (to their utter dismay) attempted to write a software program to store the data collected by the paper patient-intake forms. Written during (and mainly after) clinic hours, powered by an antique generator that supplied both power and carcinogens, on a single machine that would barely serve as a paperweight at Microsoft, TimmyCare v0 was born.

It succeeded in its objective to store the data collected on the paper forms, but not much else. After running for the few remaining clinic days, it was apparent that TimmyCare was not scalable. Charting hundreds of patient intakes on a single machine proved to be far too time consuming, and usually resulted in degenerative neurological disorders. Nevertheless—aside from the brain hemorrhaging that ensued from its use—TimmyCare had the potential to not only make Timmy’s clinics more efficient, but also to give Timmy insight into its data, something previously impossible.

Henceforth was born the EMR that would need to run in real time during clinic—often in remote locations that lacked Internet, power, and sometimes even shelter from the elements. The software would have to run fast enough to allow Timmy to see upwards of a hundred patients a day, be intuitive enough for medical and student volunteers to learn on the fly, advanced enough to justify the investment and development effort, and cost nearly nothing.

Version 1.0

Version 1.0 of TimmyCare began with a complete re-write in Redmond, WA by two software engineers who were on the initial 2011 medical trip. The verb “re-write” does a great disservice to the actual act that was performed as code was purged and memories were repressed… The focus was on digitizing the paper intake forms, schematizing a database that would allow for extensibility, and allowing the software to run on as many machines as possible, simultaneously. Since all of the machines used in Timmy’s clinics would be donations (and therefor older than time itself), the program couldn’t make any assumptions about the hardware it was running on.

Given those requirements, the clouds parted and it became clear that we should run TimmyCare as a website! A website would enable nearly any hardware asset to access the system, provided it had a browser. The website model inherently facilitated simultaneous processing of a patient, something paper—to its total and utter disappointment—would not allow. As a website, scaling TimmyCare to work with more devices, clinics, and providers was rather trivial, and destroyed zero rainforests in the process.

Fast forward 1 year to November 2012: the new version was deployed once again in Tena, Ecuador. A server and router were donated, along with 8 archaic laptops (each weighing slightly less than a car), and 5 inexpensive tablets, which turned on just over 40% of the time. The data collected from the v0 offering which was still running in Tena, was migrated to the new schematized database. Each clinic day, hosted in a remote village deep within the rainforest, was transformed into a mini datacenter. Bushes were burned, grounds were cleared, and Wi-Fi networks were broadcasted. No one was hurt, directly.

To our dismay, there were many issues with the software in that deployment. It was slow, its uptime wasn’t very high, and it wasn’t intuitive for the doctors or nurses. In its defense, the students loved it—but they don’t save lives (yet), so it doesn’t matter what they think really. Each night, team TimmyCare would assemble with the medical professionals and take notes as they bashed the software without restraint. Then we would make our immediate changes, which were deployed and tested the next day in clinic.

The Aftermath

By the end of that medical trip, TimmyCare was far more stable, hardly crashed at all, and was finally beginning to please the doctors, all the while making the Triage and Pharmacy stations the fastest they had ever operated!

 The main objective was close to complete by this point: Timmy Global Health was finally able to harvest data from its medical trips, and the EMR-enabled clinic was actually running faster than it had with paper patient-intake forms. (The reader is encouraged to re-read that last sentence multiple times).

At this point, the question of whether TimmyCare is actually being useful is still not answered, but we’ve at least overcome the question of it being usable! To answer the usefulness question, TimmyCare version 2.0 needs to demonstrate value added. So for now, it’s back to the lab again! More updates to come soon.

0 Comments

Leave a reply

Your email address will not be published.