PIH-EMR

The PIH informatics team’s blog

  • PIH logo

Archive for the ‘Rwanda’ Category

Rwanda: Upgrade to OpenMRS 1.6 with sync module

Posted by ellenball on June 8, 2010

The Rwanda OpenMRS servers were upgraded to OpenMRS 1.6 in May 2010.

The Northern Provinces have a single server in Butaro, and that was upgraded in early May from 1.4 to 1.6 by Dave Thomas, Edwin Musonga, Marc Harrison (Paris).

Maros Cunderlik, Ellen Ball & Edwin Musonga

The Eastern provinces were upgraded with a replacement of OpenMRS (sync branch 1.4) with OpenMRS 1.6.2 along with the new sync module (RC1).  Thanks to the dedication of volunteer extra-ordinaire Maros Cunderlik, Dave Thomas, Edwin Musonga, Ben Wolfe, Marc Harrison and Mark Goodrich.  The process was very smooth (if not along some bumpy and scenic dirt roads in Rwanda).   The Rwinkwavu server was replaced on Tuesday morning, May 25th and followed by visits to Kirehe, Rusumo and Rukira on that same day.  The next day (Wednesday), the servers were replaced in Mulindi and Nyurabuye.

Dave Thomas and Edwin Musonga heading back to ambulance transport at Mulindi

The quote at the end of day 2:   “Things are working” –Maros

Thanks to Biega for morning coffee and providing some sanity.  Apologies to all the goats that gave their lives to become brochettes at Coco Park.  Great appreciation to Cheryl Amoroso for dealing with some challenges with sync during the past year+.

Advertisements

Posted in Rwanda | Tagged: , | 1 Comment »

A Check Digit for Polyphemus

Posted by chaseinrwanda on June 26, 2008

“‘Cyclops, you asked my noble name, and I will tell it; but do you give the stranger’s gift, just as you promised. My name is Nobody. Nobody I am called by mother, father, and by all my comrades.’

“So I spoke, and from a ruthless heart he straightway answered: ‘Nobody I eat up last, after his comrades; all the rest first; and that shall be the stranger’s gift for you.’

–Odyssey, Book IX

Ever since the age of myth, the human race has been engaged in an epic struggle against mistaken identity. Oedipus unknowingly kills his father and marries his mother, because he does not know their true identity. The unlucky neighbors of Baucis and Philemon in Ovid’s tragic tale could have been spared if only they had a better way to accurately identify guests. Belle was lucky enough that the Beast’s true identity was a handsome prince, but most of us would prefer to know in advance. And of course, “Nobody” knows better than the now-blind cyclops the importance of accurately identifying visitors.

In the medical world, mistaking a patient’s identity can also have severe consequences. Imagine the following scenario. Annie Nonymous goes to the clinic for a scheduled visit and has blood work done. Annie Nonymous has a system ID of 12543912. The lab technician, who enters hundreds of lab tests into his computer every day, mistakenly types in Annie Nonymous’s system ID as 12543412 (which is actually the ID for Anne Nonymous). The next day, the doctor sees Annie’s CD4 count in Anne’s file and mistakenly starts Anne on ART instead of Annie! Of course, this is a simplified scenario, and in reality there are more opportunities to catch mistakes before they result in a change in drug regimen, but medical mistakes based on mistaken identity are indeed a serious problem. In fact, according to the Institute of Medicine, in the United States alone medical errors lead to around 100,000 patient deaths per year [1].

At Inshuti mu Buzima, we are taking a big step forward to prevent mistaken patient identity. From the beginning, we have been issuing patient identifiers that are verified with a check digit, generated according to Verhoeff’s Dihedral Check Digit Algorithm [2]. A check digit is a simply a letter appended to the end of an identifier that is calculated from the rest of the identifier string. You can play with generating check digits here: http://rwanda.pih-emr.org/verhoeff.html.

Although we have been issuing identifiers with check digits from the beginning, until now we had not actually been checking that check digit anywhere in the EMR. OpenMRS used to have the Luhn Check Digit Algorithm hard-coded into place, but we have recently rewritten the OpenMRS core to allow the addition of any check digit algorithm of the one’s choosing. We prefer the Verhoeff algorithm over Luhn because the Verhoeff algorithm guarantees to catch all single digit replacements and transpositions of adjacent digits. For example XXXaXXX will never have the same check digit as XXXbXXX, and XXXabXX will never have the same check digit as XXXbaXX. Luhn can also detect any single digit replacements, but it does not catch all transpositions of adjacent digits.

Now that we have the tools to detect mistaken identifiers, Cheryl, our data manager, is feverishly working to correct identifiers in the system we know are invalid, with the peace of mind to know that more will not be created. Although check digits are not able to prevent all cases of mistaken identity, we’re confident that together with the other systems of checks and balances we have in place, mankind’s ancient struggle against mistaken identity may be drawing to a close.

[1] To Err is Human:Building a Safer Health System. Institute of Medicine. Washington, DC: 1999.

[2] Wagner, Neal. “Verhoeff’s Decimal Error Detection”. The Laws of Cryptography with Java Code. p 54. San Antonio, TX: 2003. http://www.cs.utsa.edu/~wagner/lawsbookcolor/laws.pdf

Posted in Rwanda | Tagged: , , | Leave a Comment »

Synchronization… at last

Posted by christianallen on March 4, 2008

It’s not time to throw the confetti yet. But maybe we can throw just a little for now.

In November, the EMR Team attempted to rollout an edition of the EMR at the Rwanda Project that included “Synchronization”. Synchronization, for those of you that haven’t heard this little buzzword, is the ability for different machines to automatically communicate data about our patients back and forth with each other. The benefits of this are many. We can have offline entry in at sites with no computers or electricity by bringing a laptop and then have that data copied back to a central database. In sites like Lesotho where there is no internet connectivity at some of the sites, a single roaming data team member can go from site to site collecting data on a flash drive and then have it merge in to a central EMR database back in Maseru. Theoretically, data from all project sites could be accumulated in Boston for high-level analysis.

The rollout of the Synchronization Edition of the EMR was a tricky process for 2 reasons. For one, Synchronization was the single largest change to the system since the creation of the new EMR (EMR 2.0, aka OpenMRS), not to mention the most likely to cause corruption of medical data. Secondly, the rollout had to take place in a relatively short window of time during which a member of the EMR Team was actually in Rwanda. Sadly, on the day of launch the shuttle failed inspection, and Synchronization was held at Cape Canaveral indefinitely, until another window opened.

In Febuary, the skies opened again for the Synchronization Edition of the EMR to launch. This time, with luck and hard work on the part of a few dedicated developers, it passed inspection and the countdown began.

5…4…3…2…1…

On February 7, the button was pushed, and another, identical EMR came online in Kirehe. For the remainder of the day, all changes and entries that were done in Rwinkwavu magically appeared minutes later in Kirehe. Changes made in Kirehe magically appeared minutes later in Rwinkwavu. A team of extremely nerdy people looked on from a control room with anxiety and awe. By 5pm, the data entry teams had gone home for the day, and the shuttle appeared to still fly straight. It was a brief but welcomed victory.

The next day, Synchronization held strong again. And the next day. And the next. By the end of the first week of usage, the team encountered their first minor setback, but the problem was quickly corrected and the launch back on target. Another week went by. Still no problems.

At this point, Synchronization has been running without error, copying all kinds of data back and forth between the distant project sites for almost 4 weeks. To date, it has successfully copied over 75,000 changes between the sites. It is done so automatically and in the background. The entry teams working at the sites don’t even notice that it is happening, but instead can focus on the priorities and daily tasks. The only thing they really notice is that now entry is fast and efficient, since they have their own, local version of the EMR.

Most hospital systems in the Western world are unable to successfully set up systems that provide universal access to patient data, such that a patient can check in to multiple facilities and those facilities have instant (yet secure) access to their patient charts. But we have it in the Eastern Province of Rwanda. And we’ll have it soon at our other sites.

So why no confetti yet? Because we’re not finished. There still remain a growing number of sites in Rwanda that don’t have their server set up yet. Or they have a server that is being tested, but hasn’t been shipped out to the site yet. Also, Synchronization is not yet ready for the greater OpenMRS community – the vast number of people who have started to use our EMR. It still needs a simpler and more intuitive setup process.

No – there will be no confetti and champagne for Hamish, Darius, and their team yet. But maybe, just maybe, we could throw a *little* bit for this one small step for the EMR Team.

Posted in Rwanda, Uncategorized | Tagged: , | 3 Comments »