InSTEDD Team Blogs

InSTEDD introduction in Asia

admin — Thu, 04 Sep 2008 15:16:00 -0500

I usually watch my very bright and articulate colleagues post blogs, but it’s been a great few weeks, with a collection of significant public efforts, and some of the efforts need notice. Let’s try a few photos this time.

My last blog was related to the Myanmar cyclone and our work on Sahana translation into Burmese, and, in the background, a very little about the Sichuan earthquake in China. I need to catch up a bit and put some other recent events in context.

Here at InSTEDD we’ve done a few things over the past three months that would be worth describing in detail but this blog would be excessively long. I’ll keep it more brief by just mentioning that we’ve:

1. Had useful meetings with the Gates Foundation,

2. Given a nice presentation at the Pacific Health Forum,

3. Hosted an interesting dinner at the Pacific Health Forum on "Ethics in Information Dissemination within Low-Resource Environments" (with WHO, PATH, Gates, Veratect, Grameen Bank, and a dozen others),

4. Chaired a useful workshop at SciFoo Camp on “Discovering Emerging Infections”,

5. Had some good conversations with HealthMap at Harvard on integrating our complimentary toolsets,

6. Presented at Kofi Annan’s Global Humanitarian Forum on using collaborative tools for climate change monitoring,

7. Had some fascinating and helpful discussions about design with IDEO,

8. Written a White Paper for the Rockefeller Bellagio Conference on “Collaboration in Emerging Infection Epidemiology”,

9. Co-chaired a track at the Fortune Brainstorm Tech conference on “Technology for Peace”

And more. It’s been an incredible summer. I’ll also mention only briefly that we received a lovely gift from the Chinese government for our work with the Yunnan Center for Disease Control after the earthquake.

Let’s stay more current in the discussions below, but any reader can feel free to ask me about anything above.

Just looking over the past three weeks:

Partnerships:

Grameen: Dennis Israelski and I just spent a week in Bangladesh with both Grameen (Led by Yunus, Nobel Peace Prize, 2006) and BRAC, the largest NGO in the world. You’ll see a selection of photos below. Starting with Grameen, Dennis and I met extensively with the director of Grameen Solutions, Kazi Islam, had lunch with the Grameen Solutions Board of Directors, and took a trip to rural central Bangladesh as guests within a neighborhood Grameen Bank microfinance meeting.

We also visited one of the Grameen Health Centers where disease monitoring is taking place by sending staff from these centers to a network of villages each day, then reporting the conditions in the villages to a doctor in this center.

Those who run the Health Centers are asking for GeoChat on a model very similar to what we intend for the MBDS cross-border sites.

These ladies are a part of the network developing for village disease reporting because they are, of course, already a network.

Grameen neighborhood microfinance meeting, three hours north of Dhaka (Dennis and I were the guests of honor):

Grameen Microfinance loan family in Tangail village:

Grameen Solutions, Grameen Tower, Dhaka:

Grameen Health Center entrance (woman in pink coming out). Counter is the Grameen pharmacy:

Grameen Health Center clinic room:

A woman from Grameen Health Center who goes to six villages every day for health reports. This is our GeoChat use-case:

Shafqat, the CTO for Grameen Solutions. Ed and Robert wrapped into one, plus a beard, cap, and thobe. Speaks gorgeous British English, native Bengali. Smart, cheerful, very impressive man. The smile was constant. We saw a lot of his work.

BRAC: BRAC is, to my understanding, the largest NGO in the world. They work generally on primary education, children’s health, and gender-based microfinance. They have recently started a school of public health on a model that is considered one of the best in the world.

Dennis and I met with the Dean of that School, Professor Mushtaque Chowdhury, for a discussion of an Innovation Lab linkage between that school and the Cambodian School of Public Health, the topic to be “collaborative public health epidemiology and informatics”, teaching our methods and our tools sustainably in a format that gains credibility and academic rigor.

Professor Chowdhury (who is also a full Professor of Epidemiology at Columbia in New York) liked the idea very much, as did the Cambodian National Institute of Public Health, overseers of the School of Public Health in Phnom Penh. We’re working now on a proposal to link the two, since BRAC wants our tools for their school, Cambodia wants the BRAC curriculum model and our tools, and we want to ensure sustainability for the collaboration meme in public health informatics. How better than to embed it carefully and responsibly in the educational systems?

MBDS: Dennis and I then joined Ed Jezierski in Phnom Penh for the Mekong Basin Disease Surveillance Network (MBDS) Regional Forum, the Coming Out party for our tools and methods within the medical and public health providers for six nations in Southeast Asia. Photos below. Dennis, as co-chair of Information and Communications Technology (ICT), spent a lot of time at the podium and leading ICT workshops. We were (and are) only technical advisors and NOT technology implementers (Very Bad Idea) but Dennis had a decent bit of responsibility regardless.

We also, at this meeting, hosted a mini-conference for the demonstration of our tools. It took place on a Tuesday evening from about 5pm to 8pm. Photos below. We had a remarkable turnout – 73 registered attendees – and we had a TON of questions, comments, people trying GeoChat submissions in real-time to the number we gave them, and lots of post-event crowds around each one of us.

Despite our groaning internally about the somewhat clumsy delivery process we used for our message, and more technical difficulties outside of our control than we really wanted to endure (broken cables, failed phones, loss of hotel internet halfway through, etc) we were apparently a pretty good story anyway. We have a page of requests for collaboration including WHO’s WIPRO office in Manila, the Ministry of Health in Laos, the Yunnan CDC in China, ProMED-MBDS, US-CDC in Asia, RAND Corporation, and a dozen others. We were hot.

There will be a trial of our stuff around a dedicated ICT meeting in Savanakhet, Lao, probably in early November. At that point we will have Stung Treng and Champassak already explored in September (I hope), and we’ll arrive a day or two early in November and try linking – for the meeting – Mukdahan (Thailand) and Savanekhet (Lao PDR), and Savanekhet and Quang Tri (Vietnam). They are already rather tech savvy and have been cooperating with each other so this should be a small step for a trial. That will give us trials of cross border links in Cambodia, Vietnam, Laos, and Thailand before the end of the year. Not bad.

Dennis co-chairing ICT. He did an outstanding job on short notice, gently encouraging participation. It was gratifying to watch and very carefully and respectfully done:

Ed choosing phones for our workshop:

The MBDS InSTEDD Coming Out Party – GeoChat in real time from the audience:

More attended than we expected. We’d had a little warning that day so we shifted the workshop venue to the plenary hall.
(note the GeoChat submission in progress in the foreground)

Post-event discussions – we were pretty popular:

Tools

GeoChat: Now available. This week it grew from weak as a kitten to perhaps the maturity of Baron Rojo, Ed’s very large puppy. It’s not a mature tool yet, but it’s clearly no longer just embryonic potential. We used it in Phnom Penh with strangers on the fly and it worked well. I used it at Burning Man this past weekend. We’ve been asked to have it available for hurricane season, and we’ve been asked to introduce it to the WHO regional office, WIPRO, in Manila for their field staff.

OK, good stuff. We’re getting out there effectively. This one hit the mark.

GeoChat, the day before the MBDS demo:

Riff: Riff, our collaborative decision support tool, works well, and just as designed within the internal architecture, but it needs, I think, deeper exposure in the field to optimize the user interface. I think, to start, I want to start using Riff daily beginning this coming week within my own office.

As it happens, we had a PERFECT Riff problem appear in India while we were at the MBDS meeting and - disappointingly - we all wound up discussing it on a series of disjointed emails around the world. Riff is designed to help with precisely this problem - teams of people around the world collaborating quickly around a news item with a number of bots and automated services to help users make informed decisions with context. Unfortunately we were only a couple of days from having it ready. We’re there now, but we missed that brief window. Rats.

We are also making sure GeoChat messages go into Riff seamlessly and show up on a map module that we can then annotate for GoogleEarth through Mesh4x. We will be very sure our creations gracefully understand one another.

In Riff we really need to transform a complex set of capabilities into a look that is clean, intelligent and intuitive and I'm not sure we're there as well as we could be. This may be a place to ask for help:

If there are bright designers out there who would like to help with some open-source humanitarian software UI design that we give away for free for use in Very Bad Places, please drop a note to Info@instedd.org or write me directly at Rasmussen@instedd.org. I’m looking for clever, creative ideas for helping Riff be a better interface on top of the already superb capabilities built into the features and modules. This tool has to be effective in helping users collaborate when they're hot, filthy, exhausted, a little scared, badly overburdened, and responsible for lives.

Below is an older version of Riff (perhaps three weeks), one view. It looks quite a bit better than this now, but it’s still in process. Note that the function really is quite decent. Its only the interface that is not yet intuitive.

Mesh4x: Mesh4x, though the most technical of our products and the one with no user interface, is probably our most successful beast to date. It’s now been built into the OpenROSA effort called JavaROSA and will be introduced in Tanzania within the next month as a part of OpenROSA / OpenMRS and will have genuine use in the field. To quote Mulan, “our baby’s all grown up and saving China” (overstating somewhat and getting the geography wrong).

Mesh4x does a lot of linking from one thing to another, is fluent in several important computer applications, and plays very well with other communications devices.

Mesh4x is also, curiously, the easiest story to tell: Bad disaster, lots of tents on the hillside where humanitarian staff are working, assessments happening everywhere and being saved in Excel or Access or GoogleEarth, so lots of people collecting lots of information in stovepipes. Very inefficient, and maybe unsafe.

So then (socially) we agree to share information and bits of interest, then (technically) we introduce Mesh4x. Now, with Mesh4x helping, I move my pushpin on Google Earth in my tent, your Excel spreadsheet in your tent changes, we’re all sharing information in crisis, it’s efficient, with less redundancy, better use of donor dollars, and it’s all over SMS with no internet, using freely available libraries. Easy story. Great utility. Interesting idea. Perfect.

RNA: RNA is a set of tools (modules) within Riff for analytics and they are better than I thought it would be at this point. It might be the best of the Riff module set and has surprised a few people with it’s accuracy both in diagnosis and in defining relationships.

RNA is a distinct tools set, even though within Riff, and so we look at it separately. It’s apparently going quite well, using a team led by Dr. Taha Kass-Hout and involving Nico in Argentina and some interns from Trinity College who turned out to be excellent (or well-led? Or both?). We’ll keep this going. You can read about it on Taha’s blogs.

Tracker: Tracker is our web aggregator for health and humanitarian technology stories. We kept finding such great stuff buried in obscure places that we thought we had to build something that would allow us to share the new discoveries and capabilities with the entire humanitarian and global public health communities. It will be up for us this coming week.

Tracker, I’m told by reliable people, will be informative, well-designed, appealing to look at and interact with, and effective to use. We’ll know very shortly.

I’m pleased to note that, on Tracker, we’ve been involved with the humanitarian blogging community, UN relief agency staff and former staff, news organizations, NGOs, and others making sure content and form are aimed well. The feedback has been very positive and a number of sites are watching for us. I suspect we’ll get known pretty quickly.

Here is a screenshot from two days ago. Looks very encouraging. Clean, smart, interesting. We’re populating the resource databases this weekend:

As a last thought, my special compliments to the Clarius team working so closely with us in Argentina and in Cambodia. Daniel, Nico, Laura, Miguel, Luigi, and the rest are truly among the very finest coders, testers, QA staff, designers, and teachers I’ve ever run across. They’ve been doing consistently outstanding work, under great pressure, across a 15 hour time difference, and across really challenging communication systems, in at least five countries.

All of their work has been done with care, cheerfulness, competence, and flexibility and the result has been a stunning output, with four major efforts ready for release from a small team in about eight months, starting from zero. It's a remarkable accomplishment.

Let me here, publicly, convey gratitude and admiration to each of them from all of the staff at InSTEDD.

Eric

Collaborative Analytics and Environment for Linking Early Event Detection to an Effective Response

admin — Tue, 02 Sep 2008 02:41:00 -0500

A system for early detection, situational awareness and coordinated response is essential to effectively mitigate the threat (morbidity and mortality) of a health-related event and to improve health. The progress made to-date in biosurveillance worldwide is significant and should be evolved to meet existing and emerging needs. There are existing processes, relationships, technologies, policies, infrastructures, and advances in science and technology that provide a solid foundation to a truly integrated biosurveillance solution. Of paramount importance is the need to strengthen the capacity and enable data-driven decision-making of public health services from the local to the district, national and global levels—both strategically and tactically.

In looking at the current landscape; however, we found the majority of the designs, analyses and evaluations of early detection (or biosurveillance) systems have been geared towards specific data sources and detection algorithms. Much less effort has been focused on how these systems will "interact" with humans. For example, consider multiple domain experts working at different levels across different organizations in an environment where numerous biosurveillance algorithms may provide contradictory interpretations of ongoing events.

Nico and I have been working on project codenamed RNA (or Event Evolution) to provide the public health, disaster and humanitarian communities with 1) a "collaborative” virtual environment supporting the entire life cycle of an event, and 2) a ubiquitous biosurveillance capability. Our objective is to connect early event indications to a coordinated and timely response, therefore reducing the response cycle. Through a hybrid (event-based and indicator-based) surveillance approach, we aim to provide processes, methods, and technology tools for streamlining collaboration between domain experts and machine learning algorithms. By synthesizing a wide variety of health-related event indications into a consolidated picture, RNA is anticipated to help the user community to:

Rapidly identify, characterize, localize, and track health-related events
Maintain a global awareness of the situation
Integrate and analyze data relating to human health, animal, plant, food, and environment
Disseminate alerts

The humans are essential part at every step of the life cycle of an event. Humans understand the meanings of information, languages, images, etc. better than machines alone and can make contextually relevant collections of information. Each collection can build the power of the knowledge network in order to corroborate or refute different hypotheses especially at the early and sketchy stages of an event.

RNA will consist of several high-level modules, including:

Data processing
Automatic feature extraction, data classification and tagging
Human input, hypotheses generation and review
Predictions and alerts output
Field confirmation and feedback

The data processing module allows users to assimilate, broker, and/or collect information from several sources (SMS messages (e.g., Geo-Chat microformat), RSS feeds, email list (e.g., ProMED or ProMED MBDS), documents, web pages, scholarly publications, electronic medical records, animal disease data, environmental feed, remote sensing, VoIP, alerts, etc.). A number of ontologies (geographical and disease) will be supported in multiple languages, including: English, Spanish, French, Japanese, Vietnamese, Thai, Korean, Chinese, Arabic, Russian, and Khmer. Disease ontologies will include: Medical Subject Headings (or MeSH), Systematized Nomenclature of Medicine--Clinical Terms (SNOMED-CT), Logical Observation Identifiers Names and Codes (LOINC®), and The International Classification of Diseases (ICD9/10.)

The automatic feature extraction, data classification and tagging module is extensible allowing the introduction of machine learning algorithms (e.g., Bayesian). The components of this module can extract and augment features (or metadata) from multiple data streams; such as: 1) at the earliest stages of a disease outbreak it extracts source and target geo-location, time, route of transmission (e.g., person-to-person, waterborne), 2) at the later stages of a disease outbreak it provides detection and suggestion of tags for new sources based on the evidence on other sources using Support Vector Machines (or SVM) (as will be discussed below). Additional feature extraction include "data decorators"; for example, extracting features, such as: soil moisture, temperature, and mosquitoes density from a reference NASA remote sensing database during a suspected Dengue fever outbreak investigation following heavy rainfall and flooding associated with the landfalls of a hurricane in the Lower Rio Grande Delta. In addition, these components help detect relationships between extracted features within a collaborative space or across different collaborative spaces (e.g., Riff, the ProMED MBDS network.) We plan on using a smaller but more comprehensive set of event classification as follows:

Large aerosol release
Building/vessel contamination
Small release or contamination
Continuous or intermittent release of an agent
Contagious person-to-person
Commercially distributed products
Waterborne
Vector/host –borne
Sexual or parenteral transmission

This high-dimensionality of threat space classification can be further reduced to:

Single or focus event
Continuous/sustained event
Distributing/disseminating event

With human input, this module can help suggest possible classes (or a combination of classes) depending on time, space, and where we are in the life cycle of an event. Possible classifications include the following (Note: All tags/classifications can follow a hierarchical construct):

Syndromes (e.g., dermatological, gastrointestinal, musculoskeletal, neurological, respiratory)
Symptoms (e.g., fever, cough, sore throat, diarrhea)
Routes of transmission (e.g., person-to-person, waterborne, foodborne, aerosol)
Diseases (e.g., TB, HIV, Influenza, Influenza/Avian Influenza)
Hosts (e.g., human, animal, plant, multiple)
Time and geo-location (spatio-temporal features)

For example, at the earliest stages of an infectious disease outbreak, classification of an event could indicate that “there is an unknown respiratory event, transmitted person-to-person, detected in location X, and is spreading with a Y spatio-temporal pattern, across regions Z1, Z2, and Zn.”

The human input and review module is exposed as a set of features that allow users to comment, tag, and rank the elements (positive, neutral, or negative). Additionally, users (or groups, such as communities of interests) can generate and test multiple hypotheses in parallel, further collect and rank sets of related items (evidence), and model against baseline information (for cyclical or known events).

With that information together, the field confirmation and feedback module helps maintain and record history of a list of ongoing possible threats. Components in this module allow domain experts to focus their field investigation and information gathering in order to confirm or refute hypotheses under consideration. Feedback information is then fed into the virtual collaborative network to update (increase or decrease) the reliability of the sources and credibility of the users in light of their inferences or decisions. By analyzing the factors contributing to the identification of various events, it will be possible to help future epidemiologic investigation through play-back or retrospective analysis. Possible information we anticipate recording include:

Which automated systems generated the most reliable alerts, and for what types of conditions?
Which human users where the most effective in identifying conditions?
Which indications are the most effective in identifying a health event?
What factors help to minimize or aggravate a health event?
Which elements of the biosurveillance life cycle require the most time and/or collaboration?

The network history can provide a common point of evaluation (for the overall situation awareness and the individual processes of the biosurveillance network) for a variety of surveillance and response techniques.

Over the summer, the Humanitarian FOSS (HFOSS) Project Summer Institute 2008 (May' 08 - July' 08) carried out an internship project mentored by InSTEDD and a number of HFOSS faculty. During this internship, Juan Pablo Mendoza and Qianqian Lin developed ALPACA Light Parsing And Classifying Application (ALPACA) to:

Transform raw unstructured documents (e.g., news reports, ProMED mail, etc.) into machine readable and analyzable data using a text parsing module
Categorize documents using a SVM classifier using libSVM for: a) Classification into a predetermined (user-defined) list of categories as described above (syndromes, symptoms, routes of transmission, diseases, etc.), and b) Suggesting additional tags and/or topics using a Naive Bayes classifier given existing topics and monitoring human input and review. This is especially helpful with new (emerging) threats or those threats that we know about but we experience them at a much bigger scale than usual (e.g., far more virulent flu virus than we’ve experienced over the past few years)

We tested ALPACA against two widely accepted early sources of information in the public health community; Reuters news and ProMED mail. Results are shown here:

ALPACA is extensible through a plug-in functionality that provides a simple way to add additional parsers and classifiers to the application. We are continuously adding and testing additional algorithms and we welcome your contribution to help us better calibrate existing classifiers and parsers as well as introduce additional ones (you can visit our collaborative space here.)

With RNA we hope to provide the user community with a ubiquitous capability that enables detection, prediction and response to health-related events through a collaborative environment that combines data exploration, integration, search and inference—providing more complex analysis and deeper insight. We've demonstrated RNA's initial capabilities (feature extraction, classification, and tagging and item clustering with a spatio-temporal context) as part of Riff and leveraging mesh4x during a demonstration for the MBDS in SE Asia last week. In the future we also plan to offer RNA as a service that can be integrated with other platforms and networks.

The analytical and collaborative support does not end at the early detection of an event; we envision RNA to provide a rich and flexible functionality during and after an event for maintaining situational awareness, effective response planning, and evaluation. We plan on providing RNA's libraries, tools and applications in the Google Code soon. In the meantime, we look forward to your feedback and contribution.

Some Definitions

Public health: "is the study and practice of managing threats to the health of a community. The field pays special attention to the social context of disease and health, and focuses on improving health through society-wide measures like vaccinations, the fluoridation of drinking water, or through policies like seatbelt and non-smoking laws. The goal of public health is to improve lives through the prevention and treatment of disease. The United Nations' World Health Organization defines health as "a state of complete physical, mental and social well-being and not merely the absence of disease or infirmity." In 1920, C.E.A. Winslow defined public health as "the science and art of preventing disease, prolonging life and promoting health through the organized efforts and informed choices of society, organizations, public and private, communities and individuals." The public-health approach can be applied to a population of just a handful of people or to the whole human population. Public health is typically divided into epidemiology, biostatistics and health services. Environmental, social, behavioral, and occupational health are also important subfields." [Source: http://en.wikipedia.org/wiki/Public_health]
Epidemiology: "is the study of factors affecting the health and illness of populations, and serves as the foundation and logic of interventions made in the interest of public health and preventive medicine. It is considered a cornerstone methodology of public health research, and is highly regarded in evidence-based medicine for identifying risk factors for disease and determining optimal treatment approaches to clinical practice. In the work of communicable and non-communicable diseases, the work of epidemiologists range from outbreak investigation to study design, data collection and analysis including the development of statistical models to test hypotheses and the documentation of results for submission to peer-reviewed journals. Epidemiologists may draw on a number of other scientific disciplines such as biology in understanding disease processes and social science disciplines including sociology and philosophy in order to better understand proximate and distal risk factors." [Source: http://en.wikipedia.org/wiki/Epidemiology]
Outbreak: "is a classification used in epidemiology to describe a small, localized group of people or organisms infected with a disease. Such groups are often confined to a village or a small area. Two linked cases of an infectious disease are usually sufficient to constitute an outbreak. Outbreaks may also refer to epidemics, which affect a region in a country or a group of countries, or pandemics, which describe global disease outbreaks." [Source: http://en.wikipedia.org/wiki/Outbreak]
EID: "Emerging infectious diseases (EIDs) are caused by pathogens that have increased in incidence, geographic or host range, have changed pathogenesis, or are newly-evolved or newly-recognized. Over three-quarters of emerging infectious diseases are a result of zoonotic pathogens. Evidence suggests that emerging diseases are driven largely by anthropogenic environmental changes and/or changes in human demographics and behavior. In certain areas, these factors act on a background of high pathogen biodiversity and will alter host-parasite dynamics driving the emergence of known and unknown pathogens." [Source:http://www.conservationmedicine.org/eid_overview.htm]
Biosurveillance

InSTEDD Presentation at HISA

admin — Tue, 08 Jul 2008 21:43:00 -0500

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...

| View | Upload your own

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 College 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.

Medicine 2.0™ Congress: Social Networking and Web 2.0 Applications in Medicine and Health

admin — Mon, 30 Jun 2008 20:17:00 -0500

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 SMS Adapter: Sync data without an Internet connection

admin — Mon, 23 Jun 2008 19:57:00 -0500

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:

A collection-level check: is any sync needed?
Item-level checks: which items have been added, updated, or deleted relative to the version information available locally?
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