Team Blogs

Here is the presentation we gave at HISA.

• Brief intro about InSTEDD,
• An overview of information flow challenges in health we found in Cambodia which we hear are also present in other contexts,
• How collaboration can help with those challenges, and concretely, what are the technologies InSTEDD is focusing to help with that collaboration and information flow,
• A quick overview of method: Agile practices, trying to be a good OSS neighbor, and the innovation lab we are building in Cambodia to bring the field needs and local creativity into the very first steps of future tech development.

I believe any sustainability planning is at its core an exercise in business modeling. At InSTEDD we think one way we could attain this elusive sustainability is to shift focus from having beneficiaries sustaining external efforts, into creating an environment with the capacity to generate and grow new innovations. It's harder, and there's no silver bullet, but still worth learning to do right.

PD: This first slide always gets folks' attention, by design...

I think some slides had issues converting, if you run into trouble please let me know and I'll fix it.

From the slides you may wonder what is the status of the tech we have been working on?

• Mesh4x has been extensively blogged about, with its recent addition of an adapter that lets you sync via SMS messages.
• Geochat (Overview, Details and source)  we've demoed chunks of it, but after Myanmar and the Golden Shadow exercise we knew we had to go back to the drawing board with the UI and some aspects of the infrastructure. We'll be blogging about this soon, when the UI allows again the end-to-end scenarios folks expect.
• Riff allows you to create public or private groups for collaboration around information streams by adding metadata to items, analytics and visualization capabilities. Much blogging needs to happen about this project. We have two interns for Trinity University working on the machine learning aspects of the project under the guidance of Taha Kass-Hout and Nicolas di Tada and the contributions have been fantastic. We even have an early SDK that Olaf put together while working with InSTEDD that simplifies how to build modules that extend Riff. We haven't shown because the UI has big (massive) room for improvement (in other words it's quite terrible right now in relation to the potential of the tool). Mea culpa. But folks who have seen it tell us it will be worth the wait if we do a competent job at the user experience.

  On a side note I am off to Foo Camp this weekend under the generosity of Tim O'Reilly, where I expect to learn a lot, and after that I'm straight off to Phnom Penh to continue the hiring process and setting up our innovation lab.

I am speaking at the Medicine 2.0™ conference on adapting and adopting social networking methods for biosurveillance. The conference is taking place in Ontario, CA on Sept4-5, 2008. "Medicine 2.0™ is an international conference on Web 2.0 applications in health and medicine, organized and co-sponsored by the Journal of Medical Internet Research, the International Medical Informatics Association, the Centre for Global eHealth Innovation, CHIRAD, and a number of other sponsoring organizations." The congress was organized by Dr. Gunther Eysenbach.

Here is a list of the final accepted abstracts and the Medicine 2.0™ Blog site...

I am very interested in hearing your thoughts and any input you can provide to help me better present the topic. Definitely if you know of existing or related work that I can reference will be much appreciated...

And as my friend Susanne Jul would say: Gunalchéesh [thank you, Tlingit]

Mesh4x has a new feature that allows you sync data between a local desktop, server or mobile device and a remote computer even if you have no Internet access, by sending and receiving little batches of text messages. Databases, spreadsheets and even maps can be kept up to date using the right adapters. Algorithmic work was done to minimize the number of text messages needed, and the result is having up-to-date information on both ends of the exchange. This data can be in turn shared further with other devices locally and synchronized again to the remote source.

Scenarios

OpenMRS (http://openmrs.org) is an open-source Medical Record Management system used extensively in africa (Tanzania, Rwanda, Malawi, Zimbabwe, Kenya...) and increasingly in the Middle East and Americas (Peru, Honduras and Haiti come to mind). OpenMRS is used to improve patient care and simplify the records management at the clinic where it's used. It is common for these clinics to have just one computer and have no internet connection. Cell phone coverage can be present, ranging from reliable to dodgy for voice (just 1 bar of signal is typically reliable enough for SMS, but terrible for voice or data).

There are two sync scenarios I heard about this week talking with the OpenMRS and OpenROSA teams that Mesh4x addresses. (Note - we haven't planned to do this work yet I'm just using these scenarios as concrete examples of how mesh4x over SMS can help in the context of medical record management)

Scenario 1: OpenMRS to OpenMRS sync

The clinic is updating patient records that need to be kept up to date with the province-level hospital. In this case the clinic has a computer under a desk with a cell phone reliably plugged into it, and periodically, it would sync with a similar setup in the province level. It could also go straight up to central and then down again to the province level, as province hospitals do tend to have connectivity.

Here you can see Vanra Ieng from the WHO/Ministry of Health in Cambodia showing a physical enclosure that makes sure his phones - used in a similar setup, as an attachment to a computer- don't get unplugged from the PC or power, and are used for 'intended purposes' only (people have personal phones and other means of communication as well, and he needs to make sure it keeps running as this is for a pilot on sending disease indicators from key districts to central level).

Scenario 2: OpenMRS to mobile data gathering client

javaROSA is an open source mobile client built in Java that is used for XForms-based data collection that works on lowest-common-denominator phones as well as PDAs. You can fill in the forms and send the data via Infrared, bluetooth, http (If there is GPRS available)

If I understood the conversations at the HISA meetings,they are working on a feature to send data one-way via SMS messages (serializing objects and sending them over a set of messages). With the SMS adapter, community health workers could be taking data on their mobile devices and updating centralized computers, as well as getting the latest information on the device nd updating their local information by querying for the information of patients they hadn't seen before but are facing now, or patients that have visited the clinic since the information was taken. In addition, they could even beam (SMS) information with a colleague directly, phone to phone.

In each scenario, though, how many text messages are we talking about? In our tests, starting with a large up-to-date dataset (a KML map) and added a "pushpin" with a relatively long description. It required a grand total of 8 text messages. This includes all the steps needed to compare versions on both sides of the communication, and send the new pushpin over (see Under the Hood for more details).

If there are more items that have changed, and the larger the items themselves, the more messages are required to transmit them, of course. But we think this is a very low baseline considering the outcome: up-do date information on both sides that can, in turn, be shared with more devices locally using even more economical means such as infrared or bluetooth.

Under the hood

So what does it take to synchronize data over text messages? 

1) We need to be able to send/receive SMS messages from a phone via a USB cable. In the code we abstract this behind a provider model, and the default implementation will be based on SMSLib. We envision in a future a server version, potentially using BT's web21c infrastructure to do so.

2) The mesh protocol must be reduced to a bare minimum so it is efficient to use over tiny and unreliable text messages. We do so by combining exchanges that achieve the following:

1. A collection-level check: is any sync needed?
2. Item-level checks: which items have been added, updated, or deleted relative to the version information available locally?
3. Item exchange - 2-way sending and receiving the changed items themselves. Originally we were zipping the data and sending that over if appropriate, now we are using a variation of the RSync algorithms which use creative hashing (math operations on the data) to send the minimal information over.

3) SMS is an unreliable transport and as such there is a layer in the code that compensates for this by managing message batches. A batch allows us to split up a large payload into text messages to reconstitute on the other side, tolerating messages coming out of order, dealing with lost messages, and timing out on operations that have taken too long to complete.

It is important to understand that the goal of this adapter is not only "sending" the data for a new item or "receiving" it - This adapter checks for which items to send/receive and also sends/receives the full versioning information for the item. That makes it possible to keep sharing it with other applications and users while maintaining the ability to reconcile updates and detect version conflicts.

A big kudos to Tondat who has been moving at warp speed with this codebase. The first checkin was on June 9th! The quality of the code is very high, and the ingenious use of gzip, Base91 and Rsync shows . Check out the source.

Next steps

• Finish the optimization of the FeedSync protocol (which Mesh4x uses under the covers) in edge conditions (e.g. sharing conflicting payloads).
• Implement the SMSLib adapter and test it well with a couple of appropriate phones.
• Add this capability into the demo Java application that is used to demonstrate the KML adapter. This will let you specify a phone number in addition to the http URL and the file path in the sync endpoint box.
• Further optimize formats, encoding and memory usage.
• Pursue collaborations with openROSA/openMRS that resonate strongly with the community needs we are see in South East Asia. If you think of any scenarios where this could help your technology please share them here!

References

http://mesh4x.org
http://en.wikipedia.org/wiki/Rsync

This is an exciting work towards building an environment of sharing of resources across heterogeneous and dispersed health data:

• molecular data (e.g. genomics, proteomics)
• cellular data (e.g. pathways)
• tissue data (e.g. cancer types, wound healing)
• personal data (e.g. PHR, EHR)
• population data (e.g. epidemiology)

Also, an application which can be accessed by all users as a tailored information system according to their level of authorization and without loss of information. Collaboration is the heart of this especially across multiple disciplines. In addition, many standards have not yet been realized (e.g., HL7 (Health Level Seven), the US based Standards Development Organization that currently offers asynchronous messaging), this makes a grid approach far more powerful where organizations join the grid and make their information available for querying, processing, analysis, etc.

Few challenges remain, such as:

• How do we secure and maintain high performance of such distributed structure of data integration and computing?
• How do we close the gap between grid standards and health-related standards [some nice work's been done here by Power, et al]?
• How do we go about next-generation open source ontologies for medical informatics?
• How do we close the gap between hospital policies, public health policies, etc. and the grid approach?
• How do we go about consumerism and patient ownership of her or his data?

If anything, I hope this raises more awareness of the grid application in health and public health - much still remains to be answered.

Successes are already underway in the health community, for example:

• in the European health community (HealthGrid©)
• US CDC [presentation on the Public Health Grid by Ken Hall (BearingPoint, Inc) and Dr. Tom Savel (US CDC) at the recent HimSS February 2008 meeting]

But also there are lots of lessons which we can learn from the innovative thinking of efforts like the Google Cloud (click here to learn more about cloud computing).

I'd be very interested to hear your thoughts on this...

After feedback from Where 2.0 we updated the Mesh4x KML adapter to Mesh4x to embed all versioning metadata for the items in the file itself.

This allows you to have one KML file, send it via email, copy it on USB drives, and have your team do changes on them anywhere they are. When you get their copy back again, or if they meet each other, they can use the sync utility to make sure changes are merged both ways. They can also use the sync utility to sync to a server via http, by just putting the server URL in the text box.

This week Juan Marcelo aka 'Tondat' worked on some refining touches on the adapter:

• One File: You only need to keep track of your KML file now. The sync utility will add versioning metadata as needed to the file.
• KMZ: We support KMZ which is google earth's native save format (A KMZ file is really a zip file with KML and additional resources like images or icons inside)
• Sync any KML:  You can sync placemarks, folders, styles and stylemaps.
• Folders and item hierarchies: We sync placemarks even as you move them around in the tree, or change the tree itself. Tondat tells me next week we'll separate placemark versioning from the versioning of where it is in the tree, so moving items around does not create conflict for the items.

We are also starting to update the server-side 'cloud storage' component to allow external applications to drive it. This would make it trivial to make a web app that:

• Lets you create 'shared maps'
• Lets you download the KML and you can work on it offline
• Gives you a URL to sync to with the sync utility
• Has an online web page to see the current map
• Maybe the page itself allows editing online? For example via the google maps API.

If you are interested in putting something like this together, please let us know.