Synchronization… at last

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.