Eduardo Jezierski

Controlling your Privacy with Health Commons

2012-03-27T10:33:53-07:00

If you buy into the idea that information about your body is ‘owned’ by you, then it’s obvious you should get to have a say about what happens with that data once it leaves your body. Unfortunately, today there is no clear and easy way to express how you want people to use your data. In most cases, you never even get asked.

As a result I see many eHealth project implementers making cavalier decisions about data management that impact the rights and privacy of populations, patients and doctors alike. People grab, share, analyze information they may not have the rights to, sometimes even by accident. There are so many incentives to produce and move data freely: folks could use the data for the promise of big data analysis, research publications, commercial product improvement, for the sakes of efficiency, medical research, marketing, writing grants, or operations analysis. Violating rights and expectations is especially easy as these eHealth projects tend to have a bunch of players involved, each one with their own language, objectives and culture.

Unfortunately, there is a lack of frameworks and common language in which to have a discussion about rights to share and use health data. Academics do IRB reviews, but rarely understand licensing terms. Doctors use eHealth systems but are not information specialists, but typically don't go beyond clinical and public health use. Private systems may or may not have end user license agreements (EULAs), they impose a one-size-fits-all policy, and nobody reads the EULAs anyway because they are complicated, and each one so is different. Doctors in the USA mention HIPAA, and folks from other countries snicker. Governments roll out an eHealth HIV project and the data ends up in some intern’s laptop in California because he happened to help with the database system. And as you see this information flow rarely involves the consent and opt-in of the population and health providers in whom the population places their trust.

Imagine this situation: a mom shows up at a clinic and gets a diagnostic for her child. Who has which rights on the data? What about the kid? Her mom? What about the doctor who takes the test, the manufacturer of the diagnostics machine, the clinic where the doctor works, the NGO that implemented the diagnostic program, the funder that funded the NGO and bought the diagnostic machine, the government of the country, WHO?

I was recently a part of the annual AAAS Annual Meeting on a panel about Surveillance. It was a good chance to catch up with Nigel Collier from Biocaster and get to hear some poignant questions from Vint Cerf, one of the ‘fathers of the internet’. We had representatives of all sorts of surveillance work from anti-terrorism to meme propagation to infectious disease tracking; and there I presented a sketch of an idea:

What if we created a simple licensing framework that made it clear what rights and constraints go with different bits of your health data as it gets stored, aggregated, and analyzed?

If Creative Commons licensing helps a wide sharing of creative work under predictable terms that respect the intent of the creators; could a “Health Commons” do the same thing for health data? What can we learn from the evolution of sharing of information on the web and apply it to this critical space?

I would like to one day be able to share information about my health on some mobile app, a wellness site, or a diagnostic procedure, and specify that I am sharing it with the following restrictions:

Sometimes I would say it is OK to link the data to my other records, sometimes not: it all depends on the context and what it is that I am sharing. The important thing is that I am in control of data about my health.

Or, conversely, if I am participating in some survey, taking a diagnostic, or going to a new health care provider I would like to know if my data is going to be used with a forced license on it, so I can make an informed decision about whether to actually participate or not.

How would it work?

The idea roughly sketched would be to:

Treat personal information as data covered under copyright law, with the patient/originator as the original copyright holder.
Build a licensing scheme that grants explicit rights and restrictions to receivers of that data.
Make sure the rights and restrictions are termed right so that re-licensing and aggregation have clear and simple rules.
Embed licensing options into all relevant diagnostic and medical record platforms, as well as wellness websites, social networking sites, and so on.
Communicate & advocate the framework especially building conscience in the public.

I don’t know if the license example I invented for the example above (linking to other personal information, aggregating, and use for health, science, and commerce) are ‘the right ones’. I would love to hear more ideas for the sort of constraints and freedoms a simple license would allow.

Maybe other terms would be more important. Are there levels of anonymization I could specify for my data in aggregate form? Are there clauses for natural disasters or crisis that would allow me to temporarily bypass privacy concerns in order to help me reunite with my family? The nice thing about the model is that it provides a framework in which to resolve these questions.

The genius of Creative Commons was to choose a few simple rules that would be easy to understand for many, instead of trying to make it a comprehensive license for all cases and preferences; a Health Commons would have to emulate that approach. Each time you see the Creative Commons icon it carries beneath it a smart and legally sound set of terms and licenses.

Next Steps?

If anyone feels inclined to develop this further please let me know. The idea needs work from copyright attorneys, IP wonks, IRB data geeks, healthcare providers - and most importantly, anyone in the general population who would like to have a tool like this. I am especially interested in the licensing framework required for safe sharing of personal health information. I have seen "Health Commons" used to describe a knowledge commons with intellectual property such as genetic sequences, but I think much more focus is needed on the incoming tidal wave of integrated personal data from electronic records, sensors, and surveillance.

I think especially large funders and companies who are at the intersection of humanitarian field work and scientific investments need to improve their frameworks to make sure their programs have an ethical approach to protecting rights of their beneficiaries. In the meantime, maybe they should get into the mindset that they are just storing borrowed copyrighted information...

Please leave comments if you have an opinion on the topic.

More about Creative Commons

We use Creative Commons extensively in our work at InSTEDD. Most of our presentations are explicitly licensed under CC BY-NC-SA 3.0 (Attribution, Noncommercial, Share Alike), as is the material of this blog.

Like InSTEDD, Creative Commons is a non-profit organization that can always use your support: consider donating to them here.

National Health Systems as a Fabric of Services

2012-03-25T05:11:19-07:00

At InSTEDD right now we are involved on a wide spectrum of projects. Many of our projects are short and grassroots-driven, such as our recent work with UNICEF using aerial photography to map environmental vulnerabilities in the slums of Rio de Janiero (see blog from our iLab Latin America: Part 1 and Part 2). In addition, many of our projects are longer and more complex as we help Ministries of Health or large NGOs lay the technology foundation that helps them meet better serve their country over the long run, such as our work in Cambodia and Rwanda.

These latter projects require more patience to see the impact and are sometimes more difficult to work on due to the time lines and the large number of stakeholders and interests involved. But, when done right, the long-term impact can be transformational.

We are lucky to be involved with Jembi, Regenstrief Institute and others on implementing such a project in Rwanda, under the leadership of Dr. Richard Gakuba, who works for the Ministry of Health as the National eHealth Coordinator. Dr. Gakuba is leading the charge transforming Rwanda's Health Information System. A big part of this modernization is the implementation of shared health records, terminology services, and facility and provider registries. When this phase of the project is done, Rwanda will have a variety of independent, but interoperating, web services that implement these capabilities. It may sound like a 2002 buzzword to call it a “fabric”, but it evokes the right image: a supporting net of independent but inter-woven services.

Having a fabric of services makes a lot of sense in this context, starting with the impact of this architecture pattern on human and organizational dynamics. Distributing the ownership, management and maintenance of different areas of data is appropriate when the organization itself is made of different departments with different workflows, incentives, and management styles. Centralizing all these processes and information into a monolithic block would cause a collapse as the only entity able to change things would rapidly become a bottleneck. Just the provisioning and maintenance of one big system can be an insurmountable obstacle. Modularity allows piecemeal evolution.

Benefits

Having a "fabric" of services has many advantages:

Creating an Ecosystem - services and their data can get used by others to create new "value-add services". For example, a facility registry could be extended with a call-in system to let immigrants get directions to nearby clinic in their own dialects. Enabling these value-add services (including mashups and client apps) allows the ecosystem of users (the general population, the local NGOs, the international ICT community, national and international private sector) to act like a gap-finder for better health services and businesses.

Potential for Big Data - Services provide a quantum leap over the traditional approach of keeping excel spreadsheets, access databases, and ad-hoc CSVs for research and retrospective data analysis. Data can be stored and versioned appropriately therefore simplifying future retrospective analysis. Taking advantage of these datasets comes with many challenges, however. For example, most countries do not have or enforce a framework where people opt-in to having their data stored, shared, and/or analyzed for research or commercial purposes. Rwanda has taken what I consider to be a great stance: All data that will be kept centrally about individuals has to be approved 'column by column' (using a relational metaphor). The data can be used only with scientific journal backed evidence that the information can be used to improve health outcomes within an actual project/program to do so. Notice this may turn some big data fans pale ("What, you are not saving everything centrally and then figuring out what to do with it?"), but I think it is a smarter place to start.

Steps to Open Government - While modest, the decision to have public data available as web services on the internet can be a milestone towards "open gov". Opening up government data increases accountability, trust, and feedback loops. Many governments would probably prefer to pay lip service to open data principles rather than embrace them; but there are so many benefits to doing so in the health sector that it may be a great place to start.

Example Services

What are the services that could exist in such a fabric? The theoretical list runs long but here are some examples of the services we are dealing with in the real world:

Facility Registry: A service to keep track of facilities, their admin information, the health services they provide, and data about their catchment population.
Vital Registration: Service to keep track of births, deaths and Health ID management for the population (Note that a different ID assignment authority is needed: the United State's practice of using a unified social security number for financial ID, health ID and immigration purposes is considered 'bad practice' by modern standards, and I am happy where we are working with people who are staying away from unified IDs).
Shared Health Record: Services that keep track of individual people's health data over time.
Provider Registry: A service that tracks the institutions and individuals who are licensed to work in the health system. This can be enormously important for HR, education, and performance-based-financing work. Having a current provider registry also is a foundation for maintaining privacy.
Terminology Registry: Services that collect, map and standardize the meaning of different words and fields. This makes it easier to see if the "blood pressure" field used in system A can be equated to "blood pressure" in system B (If the blood pressure is taken in different parts of the body in different conditions, the data semantics are different, regardless of the shared label).
mHealth SMS, Voice and USSD gateway: Having these help consolidate agreements with operators & aggregators and provide a simpler way to manage collections of mHealth initiatives.

Of course, having many services makes it necessary to have better federated authentication/authorization capabilities (unless you want users to forget 10 passwords instead of only one) and to have some external services that act as controllers/orchestrators for complex multi-step operations (for example, someone dying or moving may trigger a cascade of operations on all the services above).

Good neighbors

To be good citizens of the fabric, the services have to play well with each other. Here are some expectations:

Master vs Reference Data: Each service has clear ownership of master data versus what is reference, externally managed data which may be continuously updated from some external system.
Accommodating Dynamic Changes: Services-especially the registries and shared health record — have to accommodate dynamic changes in information schemas and uses over time; and provide a good long-term versioning strategy.
Updates and Queries: Services must expose a REST API or equivalent endpoints for state updates and queries, as well as expose a stream-of-events API (e.g. Atom/RSS feeds with some pingback/notification mechanism to allow other services to adjust themselves to the changes in real time or in batch mode).
Compatibility: Services share compatible approaches to authentication/authorization/auditing and other crosscutting aspects.

For the work we are doing, Rwanda has chosen use cases in maternal-child health as the 'red thread' that will drive priorities in the project. Part of their well thought out strategy is to keep governance over the technology but rely on local and international partners to help build the technology instead of having an in-house dev shop within the Ministry of health.

InSTEDD contributes the Facility Registry

Rwanda is currently evaluating good starting points for the services discussed above. For the Facility Registry services, Rwanda is evaluating Resource Map, an InSTEDD tool that was originally developed in 2009 by our iLab Southeast Asia.

Resource Map evolved to help people make better use of their data. Data that isn't used is stale, and stale data isn't used. We have seen lots of projects and facilities collect and forget about the data as soon as its reliability became suspect. Tens of thousands of dollars per country are spent every year on collecting information that could have simply received minor updates from previous versions.

Originally, we called the tool 'Dynamic Resource Map' to emphasize the dynamic nature of the tool. We wanted to ensure that the tool supported making the data operational, not obsolete. Some key aspects of the tool include the ability to define your own layers, with 'points' or resources or reports on those layers (which are shown as different fields). The tool also has query and update features that can be done through SMS and smartphones (using Open Data Kit). The tool is designed to manage a resource database that happens to have a 'geo' component to it which adds critical behaviors on top of the typical alternatives of having semantic-less spreadsheets or generic GIS tools.

A real-world example of the value of the tool is its ability to track stocks of supplies for Malaria treatment at the health center level. The simplicity of being able to just text in your current stock and have it automatically trigger an alert to the folks in the capital that will send you more medicines is invaluable.

Seeing the individual or clustered facilities with your own icons or alerts based on your rules can give you a real-time operational picture that otherwise would be impossible to visualize. Other uses include tracking of information about water quality measured periodically at different pumps, and also it is useful for project tracking and monitoring & evaluation (M&E) data gathering.

Data that isn't used is stale, and stale data isn't used.

As with any InSTEDD tool since 2007, we took the perspective of providing a cloud 'product' that is generic and usable worldwide, that each user can configure to their needs. For example, folks can add their own fields, manage their own user permissions, and have total freedom to import and export their own data, etc. And with the APIs and import/export features, people can move the data to spreadsheets or to more specific tools like ArcGIS or GeoCommons as needed.

As we work with the Rwanda Ministry of Health on their eHealth foundation, our Resource Map tool will evolve to incorporate the experiences and feedback from the people using the tools. We will use their stories to maximize the benefit to the global eHealth/ICT4D community as we develop new versions over the upcoming months. In addition, we have started engaging with other amazing implementation partners so that this work can be incorporated into the shared commons of technology. We are excited about the changes that this initiative is already bringing in the front of APIs as well.

Back to Rwanda

Here is a video with Dr. Gakuba discussing the plans and context for the work. It contains many insights from a practitioner and leader that has to make the tough decisions every day. (Note, it is a bit long and the camera just focuses on the speaker, so it's hard to flip through it.)

He warns about making implementations of health programs revolve around evaluations (instead of make evaluations revolve around implementations) and gives an idea of the progress Rwanda has made in Maternal/Child Health, and how eHealth can help further MDG goals and health delivery.

He also reinforces the importance of starting small and working directly with your users as much as possible. Dr. Gakuba also recommends deploying simpler, smaller parts in a sequence versus going after large, complex technologies from the onset. Fortunately InSTEDD’s services-based approach is a perfect fit for that strategy, which allows the Ministry of Health to stay focused on priorities and gives a more iterative, agile frame to the project.

January 11th 2011

2011-01-11T17:25:50-08:00

As January 12th approaches and with it the anniversary of the tragic Haiti earthquake, I have some hopes:

- That everyone in Haiti has a moment of respite and peace to focus on their loved ones, the ones that are here and the ones that are gone.

- That folks consider the Haitian's perspective over the international community's perspective & party line. Thanks @mediahacker for your constant voice.

- That folks have respect for the pain in Haiti over trying to celebrate an overall immaterial progress in reconstruction. This post was particularly touching for me.

- Finally, I hope that more attention gets put to the dynamics in and around Haiti on January 11th, than to the international response on and after the 12th. What would a stronger, more resilient Haiti have looked like on the 11th to start with?

Architecture, Mobiles, and Health: 10 pitfalls

2009-06-07T20:52:57-07:00

The “eHealth” space (which obviously includes the mobile, mHealth aspects), is a bit too chaotic from the perspective of a common developing country. Imagine you are responsible for ICT (Information and Communication Technology) of a ministry of health or hospital wanting to modernize to improve patient outcomes or disease detection. Where do you start? What could work and what won’t, for you? What is reliable? What is the fine print?

Unfortunately, this is not just because of a rapid pace of innovation in technology, or the extreme conditions in which these health solutions have to exist.

Some of the confusion is –unwillingly- created and perpetuated by the same organizations that are trying to help in the space. This includes international organizations, academia, NGOs, funders, open technology groups, private tech vendors, etc. Types of issues I’ve run into first-hand include:

Academic projects that collect data with preference towards information that will help to publish a paper rather than the information that will be the most actionable or help community health the most. The project rarely fits in with other technologies already deployed.
Funders that sponsor the construction of specialized, one-off, disease-specific systems, that are built from scratch even if architecturally they are the same as other specialized, one-off, disease-specific projects.
Technology vendors fostering ‘data sharing’ projects where the data ends up shared but, unfortunately, ‘owned’ by the vendor.
Open technology projects that would rather accrete features or add cool gizmos that attract users into a do-it-all system rather than open up information and let the data flow around to other applications.
Groups that would rather implement anything new, now, regardless of what already works, than to help a developing country figure out what they really need.

Some of organizations are fortunately waking up to these issues and starting initiatives to reduce their occurrence. A key component of these initiatives is to bringing in an architectural approach to the evaluation, planning, implementation and assessment of ICT needs. And fortunately these organizations have people that both know the problem space and have worked as architects in other contexts.

By an ‘architectural approach’ I mean an approach that:

Separates the discussions of capability from implementation. e.g. a medical record system is a capability a hospital needs, OpenMRS or OpenVISTA are two implementation alternatives that could fulfill that need.
Understands the role of standards in supporting interoperable building blocks that can evolve over time, not as an end in of itself.
Helps transition the end goals, requirements and capabilities of the overall health system - the ‘business’ architecture - into ‘technology’, ‘integration’ and ‘infrastructure’ architectures that only exist to support the end goals.
Navigates the tension between the potential benefits of centralized, top-down decision making around ICT versus the potential benefits of decentralized, bottoms-up decision making.

What would it look like from the perspective of an implementer if the eHealth/mHealth community took such an approach? Here are some things you could imagine:

You would get something like a capability map, a set of boxes with labels and lines that describe common elements of an eHealth countrywide health information system (HIS), including capabilities such as medical records, biosurveillance, pharmacy stock management, etc.
You would be able to write on this map which capabilities you have implemented (digitally or not), and for each capability get some performance metrics that can help you rank its effectiveness. For example, a biosurveillance component would assess the timeliness and completeness of reports. Your capability maps would help you do an assessment against this metrics, letting you see your maturity, and your weak spots. This assessment by itself is a huge asset for a country and funders, as it lets you understand the landscape before you aim your efforts.
Using the same taxonomy of capabilities, a technology team should be able to find open source solutions, papers, and case studies that describe if/how the capability can be improved. Ideally, these case studies should roll up to a community-maintained pattern library, that describes the distilled “solutions to a problem in a context” that have been discovered previously.
Any improvements can be measured over time and pilots can be assessed objectively as to how much they contribute to the goals of the country (currently, organizations running pilots set up their own measures and they aren’t always traceable to the measures a host country cares about).
Funders could work together helping implement solutions that work together and not on a per-project, per-disease basis.
Finally, any local innovations could be tracked and published against that map, helping discovery by others wanting to implement it elsewhere, contribute code, etc. Assisting the discovery and amplification of bottom-up ideas is critical as the eHealth space is very much giving its first steps.

So an architectural approach makes it easier to implement, build and fund technology for eHealth. So let’s look at what holds this space back and some potential issues that may crop up by rushing in.

Pitfalls of an architectural approach

These pitfalls are not inherent to any and all architecture efforts, rather, they are risks that can be managed and mitigated. I am sharing them because I’ve seen these sap energy out of what otherwise could have been a great contribution:

1. One Size Fits All / Blueprints with no context: I’ve seen architecture efforts fail because they create blueprints that don’t consider the target context. Think about why a city apartment is different from a beach house, even if they have a lot in common. mHealth solutions will vary country to country due to factors such as different mobile penetration, language and literacy, cultural factors, population distributions. A good architectural approach would consider context as a first-class citizen. A great investment would be to evolve pattern languages for the eHealth/mHealth space, because they inherently bring in context to the equation. This is tough, however, because understanding context requires experience and on-the-ground presence which is expensive, and requires time, and takes away the illusory charm of cookie cutter answers.

2. “Best practices” advertised while the paint is still wet: There is a huge hunger for best practices. In a new field as mHealth, things that work once get a lot of press. I always recommend focusing on proven practices rather than best practices, and evaluating on impact metrics (e.g. birth complications averted) rather than proxy measures such as adoption or usage metrics (“30 users”) or satisfaction (“so-and-so is thrilled”). The latter is especially tough because impact metrics may take months or years to budge, and while subjective evaluation is critical, many organizations work heavily with per diems that distort the value proposition of an effort (For those of you not familiar with the term, a per-diem boils down to compensation as in “If you come and [work with my project] for a day we’ll pay your staff $5 each”. Everyone would agree it’s hard to design compensation for ‘customers’ that doesn’t create conflicts of interest). A good catalog of solutions would be transparent about the impact metrics and evaluation timeframes (it ran for a week, it ran for a year) of implementations or pilots (unfortunately there are a lot of systemic disincentives on all parties involved to publish this information raw).

3. Star charts for the high priests it is common to see an architecture effort devolve into a debate about frameworks, representation and notation, a debate with language and artifacts that only ‘a chosen few’ can understand. Be wary if you see UML diagrams with OCL expressions, or diagrams that claim code generation as a goal. Notations are only useful if they help comprehension. And don’t be fooled – UML and any specialized notation has been used many times to hide bad thinking behind a veneer of formality. A good architecture effort would communicate in a language and notation that is simple even if not formal. Even better, it would provide a reference architecture and reference implementations as a starting point for common scenarios (“Show me”. Heck, you could even have virtual machines with things deployed and running). In my experience a good set of documents outlining tradeoffs and decision points go a long ways helping implementation, more than a complete Zachman or TOGAF analysis or detailed BPEL workflow.

4. Shipping technology versus building capacity a good effort would specify the relevant skills and communities needed to implement technologies, and pointers on how to get those skills, not just to consulting organizations who can drop-ship products that do the job. For an effort to be sustainable, your users have to understand the goals that the technology supports, and your IT staff needs to understand the technology better than superficially. National or regional labs like InSTEDD innovation labs would be a great asset to the ecosystem of eHealth initiatives.

5. Architecture antipatterns. "an anti-pattern is something that looks like a good idea, but which backfires badly when applied." (Jim Coplien). Sounds obvious one should avoid them but some antipatterns are like flypaper, one keeps getting stuck on them, and they aren’t well documented. Architecture efforts that rely on heavy top-down prescription are very prone to recommending antipatterns as they don’t have immediate feedback loops. To discover these troublemakers early and nip them in the bud, watch out for designs that make sense to engineers but don’t make as much sense to user; or ‘grafting’ that work in other contexts. e.g. A common antipattern is recommending single-master centralized data repositories for information that spans many sectors or agencies. Another one is assuming a process or technology that works for 2 weeks for 20 people can scale to a national rollout. Good architecture guidance would have appropriate risks associated with each capability, validated by real case studies.

6. The Master Data Model (capitalization required). This is a common antipattern, but it deserves its own bullet. The pitfall is assuming you can model the data of a domain a priori, share it across organizations and applications, and then implement software following that model. (e.g. A patient has a first name, a last name, date of birth…) It is possible but very inefficient to do things this way. Creating master data models is a huge temptation amongst folks who have reductionist/mechanist perspectives (and not much enterprise-scale software deployment experience). History has shown that small, flexible standards that can be used together tend to survive longer than larger, holistic standards that cover too much. Think microformats, on standard protocols. Model the interoperability that emerges on the internet, not in large companies. Empower your users to evolve their data models and workflows without having to call coders (if that is too hard, at least make sure local, in-country developers can change and deploy the software)

7. Filtering innovation out The desire to rationalize efforts to save resources can lead to de-duplication initiatives. Reducing duplication can save waste but can also stifle innovation by reducing the chances of discovering new ways of doing things. Many great innovations are recombinations and integrations of things that existed before. A good architecture effort should celebrate multiplicity of approaches and implementations– a better gene pool is more likely to succeed. People shouldn’t be as worried about duplication of effort as they should be about lack of interoperability between projects. That said, the amount of tech efforts in the field that I’ve seen that are funded to be duplicative from day one is staggering, but only depressing when you consider how many don’t interoperate with much at all (sometimes even on purpose).

8. The “open clique” Any architecture is a like a small language, and any architecture creates an asymmetry, of those who know about it, understand it and are behind it and those who don’t know about it or aren’t quite up to speed. The health and humanitarian space is small and cliques form much more easily than in the commercial space. An honest architectural approach would be open, and would allow critique, revision and aggregation by parties not involved in creating the original architecture documents. I like the Health Metric Network’s approach to this.

9. Forgetting about your users For a project to be successful you need to understand user priorities and how they experience technology. How many technologies have been inflicted on users because they have the right technical specifications with little regards for the user experience? How many of these technologies that users don’t like have succeeded? With mobile applications, there are many many settings and kinds of users for technology. Making things user-friendly takes more work, especially in the field. User Experience (UX) design plays a critical role in determining how technology can help the users achieve their goals. Yet I have always been amazed how most enterprise architecture frameworks miss user experience and design (or confuse it with usability and requirements gathering). Most arch frameworks are evolutions of mainframe- and client/server- era learnings generalized and repackaged for the slowly changing architectural and organizational styles used in enterprises. Consider that enterprises can afford to inflict badly designed technologies on their users much more than a ministry of health in a developing country, so I think they are a terrible role model for this particular aspect.

10. Forgetting it’s about community health the health space is littered with technologies and standards that evolved from secondary goals of the industry, that happened to be better funded for IT. E.g. standards for medical record exchange that evolved out of billing reports needed for insurance, or auditing systems that track liabilities of health care organizations but not patients or doctors. Keep the end goal in mind! A good architecture effort would make sure the outcomes and impact are correctly placed. Standards would be chosen based on how well they fit a problem, and catalogued as an implementation choice.

I hope this doesn’t sound as complaining. Rather, I am proactively sharing experience for which I have first-hand scars, after having worked in the enterprise architecture space for many years. Actually I’ve been coming back and again the idea of drafting a book on technology patterns for developing countries to share this, but would like to make it a collaborative effort. It is simpler to point out pitfalls than to steer a course that avoids them, but that was not the point of this post. Also, any architecture is a starting point, not an endgame that does the decision-making job for you: it is place from which to begin the conversations. Even with the best architecture efforts, the responsibility of coming up with the right solutions is with the implementers.

The landscape is improving

Here are some efforts I like because I think they are taking the right steps to creating long-lasting value. If you know of other relevant initiatives please feel free to add comments below

Health Metrics Network (institutional/Wikipedia)

HMN is a multilateral effort supported by funders, WHO and many organizations to define and help implement a framework for health information systems.

OASIS: Chris Seebregts and others have been putting together an effort called OASIS to help contribute to this space. I haven’t seen much official content about OASIS yet, but knowing Chris and his deep experience in the field I know that he is likely to endorse things that really work, and has direct access to the ‘proven practices’ in his work on OpenMRS and other technology efforts in Africa.

(This is not to be confused with the well-known OASIS consortium http://www.oasis-open.org/ which has IBM, Microsoft, Oracle and Sun as founding members)

Phones don’t change the world, people do

2008-12-22T02:40:50-08:00

Inspired by the Wired article “Scientists Hack Cellphone to Analyze Blood, Detect Disease, Help Developing Nations” by Dave Bullock there has been a lot of activity under the change.org post “The Cellphone that could change the world” by Nathaniel Whittemore.

Nate’s post takes on a ‘remember the future’ approach where he fast-forwards to 2011, and paints a scenario where mobile technologies are widely deployed and used. I really like that approach to visualizing possibility, and wished it was used more as a social activity. Strong Angel and Superstruct do this too, in a way. The realm of the imaginable could be further expanded by more science fiction about community and civilization resilience (This year I enjoyed reading Kim Stanely Robinson’s fiction books about the onset of sudden climate change and the response of a “fictionalized NSF” and a US govt that isn’t afraid to change). But I digress. I liked Nate’s post and the ideas there. The comments were riveting.

Katrin urged me to engage in the discussion at change.org. Reading through the original post and then through the comments (with a lot of ‘strong players’ from the mobile applications community), a couple of thoughts emerged about the state of mobile technology applications for health and other social purposes. Here are some.

In the future…where are the business models?

If you are curious, here is the reality today: In June the week before the elections I visited Zimbabwe. Here you can see a real, resilient, working Guava machine for CD4 counts on the outskirts of Harare. It uses microfluidic technology (for smaller blood samples and reactant costs) and if I recall correctly the operating principle is the same as the phone above which is a tested technology. The thing is solid, and the staff deemed it highly reliable. Calibration was not an issue. They were able to multiply the amount of CD4 lab counts manifold to 300+ per day. I was there discussing the possibility to link to the lab record system, but it wasn’t the highest priority.

A lot of the discussion did center around how disruptive it would be to have an open platform (open hardware, open software, open assays, open IP on the test methods, open reactant formulas and manufacturing) for these tests.

Just as a $99 iPhone is a red herring for the phone network costs you are going to pay every year, a cheaper test sensor that becomes widely deployed and relies on proprietary reactants has a hidden, more insidious cost.

I did not check what are the assays or lab system used by the LUCAS phone in the Wired article, and whether they are open. I just was surprised this dimension wasn’t part of the interview. I encourage Ozcan from UCLA to open-source the hardware specification to allow others to build on it!

Question: When you plug something in do you say “I’m using electricity” or “I’m using the wall socket”? Sometimes I feel the discussion about innovation in mobile tech sounds like a discussion of innovation in energy…where the discussion centers on the design of plugs & sockets. A phone is just a conduit to a network, and a powerful, sensor-rich, user-friendly device can be underused as a collaboration tool that help people work better together if network reliability and costs are not managed in unison.

In my 2011, I hope that there are hybrid social-enterprise efforts that can make inroads to working with wireless providers and carriers. They need to evolve their offerings and provide the types of cost structures needed for health and social good to scale and not depend on infusion of donations to keep running OR pushing costs where they can’t be paid while willing customers cant spend their money. Even just helping providers make money differently would help a lot. Examples: toll-free-SMS? Free-to-send? Free-to-receive? Mobile banking? Shared-costs billing? Provider-supplied location tracking of registered gov’t health staff? Anonimized tracking of random individuals for disease migration modeling? it goes on.. Providers could make more money (gasp!) and they don’t.

Beyond 2011 I hope more effort gets put into creating connectivity approaches that would be disruptive to current wireless systems. And I mean the “system” of government spectrum licensing + carriers + wireless providers + device manufacturers. But who would fund this research? Sigh…we need smaller, personal, cheaper GSM ‘towers’ that can be linked up more than phones. What would happen if every smartphone could host a 802.13 ‘peer’ network?

Centralized or Distributed mobile apps? There are no ‘best’ practices…

There are only proven practices, in context.

When evaluating whether an approach fits a new situation, you have to consider the context in which other solutions succeeded or failed. I face this all the time in the discussion of ‘centralized’ versus ‘individual’ mobile solutions. Sometimes I get asked which approach is better and the answer is a) it depends b) you want both, not either/or.

The centralized approach uses national or international-scale gateways, like Ushahidi with Clickatell, RapidSMS, InSTEDD GeoChat with Clickatell and BT, and so on. These are appropriate for national-scale programs, where reliability, performance security and availability of certain types are provided.

FrontlineSMS is the archetypical individual or grassroots approach, where a phone attached to a computer acts as a gateway where you control costs, numbers, location, etc. – providing different types of reliability, performance, security and availability for different contexts. This type of ‘individual’ solution can even run in a smartphone, and FrontlineSMS and other projects are already proposing such a migration. For GeoChat, we put it on the backlog until we saw more demand for this approach from our Asia programs.

Approaches like RapidSMS which rely on an Asterisk server can also work on a laptop, or on a server, and can help span a ‘middle ground’ between other solutions.

Scalability is important, but, I see discussions of scalability center around numbers of messages and numbers of registered users which is for most cases profoundly irrelevant. Again, scalability is context-specific; and measured by how well you grow with your users’ needs.

I know a chap –I consider him a hero- who spends most of his month travelling rural Cambodia supporting a national program to send data via SMS using plugged-phone installations. Imagine it: phones with locked enclosures get forced and misused, SIM cards swapped, chargers that burn out, USB drivers that fail, phones that lock up…Support costs of a site are his scalability denominator. For GeoChat, for example, our main scalability metric is latency of roundtrip messages under sustained use (like twitter, responses have to come out fast) across all channels (SMS, email, twitter) under large number of group users and groups.

But why one approach or the other?

Some applications support both centralized and decentralized models (like GeoChat) but as we start working together in this budding mobile community it makes sense to pool efforts and re-use each others’ technologies. I don’t see why InSTEDD for example should build yet-another-phone-detection-and-driver layer if other “social good” applications have it. For example, FrontlineSMS can forward messages on to Ushahidi (acting as a local gateway). We will take a similar approach with InSTEDD and should be emulated by the rest of the community. By working on common protocols all our apps could forward messages to each other as required (see this example as a working draft from the Open Mobile Consortium Katrin mentioned) (And Ken, if you are reading this, contributing to FrontlineSMS source was on my last years’ resolutions, and now that we got access to the source code we can really start work on integrating/implementing it with GeoChat, Mesh4x, etc… I’m optimistic about ‘09)!

The goal is to be able to pick the right tool for the context, and all the applications mentioned above are already working on protocols that would let you have a hybrid deployment that would allow you to scale up or out as needed. As contexts change, having freedom to evolve your app and not be locked into one or another is key.

Once you are moving messages around, how do you make sure different applications interpret the information in similar ways?

Shared formats for data exchange

To achieve interoperability, and reuse the human capital of having trained users, mobile apps should also share conventions on what gets put IN the messages. There is a huge gap in defining what gets put on SMS messages for diverse uses:

Free text, with specified language
Free text with explicit tags
Locations (lat/long, place names, village PCodes etc)
Delimited data (e.g. Ed, Jezierski, Cambodia)
Self Describing Data (e.g. firstn:Ed|lastn=Jez|city=Seattle
Multi-Message batching, sequenced or order-agnostic
Message batch retries
Compression
and the list goes on…

The community of builders of mobile apps for social purposes has to start catching up in this space. I suggest re-using the leadership of twitter and other services in evolving some conventions (eg @user, #tag) in common ways where applicable. I would also like e.g. Nokia’s data gathering solutions and other industry players e.g. Google to participate in the open forum, too.

For example, In the Cambodian Avian Influenza hotline pilot we implement batching and self-describing data over SMS. We should get together with RapidSMS, and define a common approach. This would let the Cambodian government switch out InSTEDDs backend and put RapidSMS transparently, if they chose to do so.

One example of this is GeoChat + JavaROSA. We want to support JavaROSA front ends to send structured data to GeoChat, and if we documented the format well, other clients (like Nokia’s?) or servers could be used interchangeably.

JavaROSA is an excellent open source project, great technology and well run. We have contributed the ability to do 2-way sync between phones and between a phone and a server, already.

Even with these agreements interoperability can also lead to a shallow openness, where applications work with others… as long as they can continue to hoard the data and lock-in users. You can see this happening over the last year in the space of social networking technologies, where many announcements of open approaches veil an underlying strategy of trying to become the ‘hub’ or the ‘one stop shop’.

Do the benefited populations really gain much if folks can collect more data, but we they can’t move it around?

Sharing Data

We all know the limits to sharing data are political or incentive-based, more than technical. But technology makes a fine excuse for not sharing information.

In the field one faces many silos – NGOs with different mandates, Government agencies with different domains (animal health, human health), research programs funded by different ivy league universities, not to mention ethnic, language and country borders.

This is an area where InSTEDD has been doing a lot of work as part of the Mesh4x project, which basically allows data to be shared two-ways between disparate systems.

Here are some latest updates

For Geeks: Progress on Mesh4x: Cloud Services, Architecture, Adapters, and Adopters – here you can see how Frontline would play with Mesh4x.
Mesh4x goes mobile with JavaROSA, allows you to sync data on your handset with no Internet

Leslie (Les) Lenert, Director, National Center for Public Health Informatics, US CDC, puts forward technologies they believe are disruptive. Better devices, data collection, and data sharing:

The goal: An Open & Sustainable Platform for the end users

Ken uses the \o/ logo for FrontlineSMS, a gesture of empowerment. I smile every time I see it.

We can’t forget that all these technology efforts are trying to empower individuals and organizations, and simplify the work of caring for one’s own community or for others.

All the teams mentioned here are working together already in different capacities towards this end goal. Resources, timelines, tools are always an issue, but over time things will be more integrated.

All the technologies mentioned here are converging towards a shared architecture –a platform for data exchange and collaboration built around mobile users in the harshest environments. A platform that can start small and grow transparently, or start large and continue running even if the centralized networks are unavailable. Because of this shared architecture, the end portfolio will be stronger, dollars spent on technology will go further, and users will have a simpler entry point to learn what are the right tools for their context.

So when a new phone comes out with a CD4 blood cell sensor, its users will know that it can send its data and “it just works”...and then go change the world one CD4 test at a time!

For Geeks: Progress on Mesh4x: Cloud Services, Architecture, Adapters, and Adopters

2008-12-12T12:11:42-08:00

As the year wraps to an end we have a mixed blessing: On one side we have a small but growing portfolio of technology stemming from our organization's immediate goals to improve disease detection and public health in South East Asia, being built at a steady pace by our small but ultra-capable team. On the other hand, the scenarios we are addressing are proving to be relevant in all walks of life of the health and humanitarian space, generating an increasing demand and with it, a simultaneous increase in breadth and depth on the demand side. Exciting times indeed!

Of our main technology efforts (Riff, GeoChat, Mesh4x, TrackerNews.net) Mesh4x (http://www.mesh4x.org) is the one that started getting the earliest deployments to the real world.

From mesh4x.org:

“The goal of mesh4x is to provide a portfolio of libraries, tools and applications that simplify using standards-based data meshes from multiple platforms and languages…”

The libraries can be used right away by developers who integrate them in their own applications, so there was no need for them to wait for a more packaged set of user interfaces and end to end experiences.

Why it matters and why InSTEDD is working on this

Data meshes have appealing characteristics for our users, so our contributions to the Mesh4x project are driven by observed data-sharing needs in the health and humanitarian space.

Symmetrical: They allow data to exist in a concurrent multi-master environment where updates can be applied at any node in the mesh.
Asynchronous: They allow offline updates to information and synchronization with other nodes without requiring data locks, essential for occasionally connected applications.
Dynamic: The synchronization can happen even in constantly changing connectivity topologies. I can sync with a server and later the sync can be done between my client and another client, who could then sync with another server if the first one isn't there, and so on.

This matters to us as these characteristics help information flow and data sharing even in the tough contexts we face:

Symmetrical: No organization or application has, de-facto, greater control over information than any other. Symmetry allows power to be shared equally amongst partners, in a true multi-master way, resulting in less hoarding of live data.
Asynchronous: Connectivity is an occasional luxury, and the most up to date information is found where it is less likely to have a connection. Storing changes locally and sharing them opportunistically keeps information moving.
Dynamic: Connections are opportunistic – you may not have Internet access at all, but you have access to local wifi networks, physical contact with other devices, etc. Data will eventually get to the desired endpoints as it leaps opportunistically between participants.

Some concrete applications of mesh4x in the space:

Mesh4x goes mobile with JavaROSA, allows you to sync data on your handset with no Internet

Mesh4x SMS Adapter: Sync data without an Internet connection

I have another blog post I should release soon that highlights the proven value of meshes and Groove in the humanitarian space, and my personal introduction to the uses of this architectural pattern.

But this post is about the progress & directions for the project.

Cloud-Based Service

In the last post we mentioned building a cloud based services as a contribution to the space. The demand was for an always-online, cheap to host, simple server that could act as a storage of data and as a relay point for devices connected to the Internet.

The implementation was embarrassingly simple on Amazon's Elastic Compute Cloud (EC2, a dynamic and virtualized hosting environment) and S3. As a matter of fact, a single Java servlet running on Tomcat + Linux and driving the Java Mesh4 sync libraries ("Mesh4j") provides the heart of the logic. Less code is the best code!

We are doing a pilot with the Center for Disease control, synchronizing their Microsoft Access-based EpiInfo application, and they asked if the health surveys they were taking could be automatically geo-mapped as the users synchronized to share their information. This led to incorporate an ontology ("schema") mapping aspect to tell the server "expose a KML feed taking THIS as the title, description, address, and timestamp for the items"

Taha describes the work with CDC on his Biosurveillance 2.0 blog and why using mesh4x will help them extend the effectiveness of EpiInfo for outbreak investigation.

We will be opening this service up progressively as we test it out with initial users and tweak it based on their feedback; I hope in a couple of months to have a tested version we can point you to publicly! In the meantime, contact us if you are interested via email or if you are a developer via the Mesh4x.org code project.

Part of the forcing function for writing this post this week is that we've been chatting with CDC, JavaROSA, and others about these store/endpoint/mapping capabilities and I'd rather we start the collaboration early before we accidentally diverge codebases or approaches.

Under the Hood

This is the architecture that the server has been going towards these last couple of weeks:

Update APIs:

These allow other applications to change the data in the service. A mesh endpoint allows FeedSync-style updates, but we'll add AtomPub for simpler edits via http POST and other RESTful verbs that are easy to manage from Javascript or are useful if you don't need the full power of the mesh. A JavaROSA endpoint will allow the right metadata to be exposed to JavaROSA or AndroidROSA handsets, and accept updates.

The GeoChat and a FrontlineSMS bridge would allow message forwarding and sending semistructured data directly in via SMS.

Storage:

This is the storage layer for all the data and the configuration, security information, etc needed to keep the service running. In our web-based instance, all this data is stored in S3, but if you wanted to host this in your own office or in a clinic, it would all be sitting inside a MySQL instance. As a matter of fact, all the mesh4x services' information is managed by mesh4x itself, so the actual configuration data is stored via an adapter.

Ontology Extraction:

Our service differs from a database in which you don't need to tell it the schema of your information up front. As a matter of fact, we would like to know as little as possible about the format of your data. We prefer to let applications change and evolve the data they use without having to ask developers to change database structures or write specific code for each case. But knowing just a little about the structure of your data helps with things such as defining mappings and filters, so we try to infer as much as we can. The Ontology Extraction component allows you to submit RDF-formed information (or XForms-based or other any other formats that has a transformer) and we keep track of (for example) what fields make up your entities. If you supply such ontologies yourself (in RDFS, or an XForm Definition)we keep it around, too (e.g. 'Patient Date of Birth is a Date/Time field' ).

Internally, we are using RDF as the default standard to represent data and ontologies. RDF has many properties that make it the simplest appropriate choice, but that would be the topic of a whole different post in of itself.

Ontology Mapping:

Ontology Mapping allows us to map fields and entities of different ontologies to help us make sense of your data. For example, to do nice map of your data we need a title and a descriptive summary, a position, and a timestamp associated with the entity. Which field should provide the timestamp? Which address or coordinate fields should be used to put an item on the map? How should the description be composed from from the data? Mappers allow us to do this, and in a future through the user interface you will be able to define these yourself.

Filtering:

Filtering is essential in a mesh where little devices and big devices coexist. You could have refugee records for a whole country in one mesh4x mesh, but on a mobile phone you'd probably only want to keep a subset of that. As soon as we expose filters it will be easy for a phone to say 'I work with patients in village X' and just sync that subset of data.

Format Transformers:

Format Transformers are components built to translate data into specific formats. GeoRSS and KML are standard formats for representing information with geographic aspects to them. You can see the KML in Google Earth, for example, and items would appear on the map as people sync their data to the server.

Transformers for XForms Models and XForms form allow us to translate the information of your entities and their ontologies into XForm formats. We see the utility and the pragmatism of XForms models as a way of exchanging records and to define the UI model of the forms users see in XForms, so these transformers allow us to go from our internal RDF-centric representations to these broadly adopted formats.

Sync Adapters:

Finally, you have all this data here, but you probably want to work with it elsewhere! Folks have suggested/requested the following as potential endpoints for the data:

Google Spreadsheets: we have a Microsoft Excel adapter, so why not a Google spreadsheet one? Imagine creating a form, having it fill out a spreadsheet with gadgets for analytics, and then. Google spreadsheets are also great when lots of people online have to work live on the same data.
Zoho is coming up with lots of useful applications. Imagine synchronizing your Zoho app with a table in your MySQL or MS-Access database.
MySQL: a lot of websites out there -for good or for bad- run with their MySQL instance exposed on an open network port. Someone we were working with in Mukdahan, Thailand (a 12-hour truck ride from Bangkok), asked the simple question: if I give you my connection string, can you just put the data there for me? Seemed simple and straightforward, so we will line it up in front of other needs!

Together with running sync adapters we will have to have some user interface to schedule these updates, define mappings between schemas/ontologies, and resolve conflicts. A nice UI for this may end up taking a big pat of the project effort, so if you can reference us to open source projects that do any of this or want to contribute, don't be shy!

These mappings are part of the mesh too, so in a future (assuming anyone requests InSTEDD or contributes the source) you could be offline and mark an excel spreadsheet as 'shared' and when you sync, not only the data would travel back and forth, but the server itself could create a Google spreadsheet endpoint (or something similar) with the same information for others in your team to use!

Putting it all together

In my next post I am explaining how all the pieces of the Mesh4x project come together to help data integration of disparate systems and helping connect these applications into a synthetic whole, instead of having dozens of islands of information.

More information

http://www.cdc.gov/epiinfo/ EpiInfo is CDC's outbreak investigation surveying tool. You can participate in their Open Source project on CodePlex: http://www.codeplex.com/EpiInfo. We are working with them to enable synchronization over the cloud of their MySQL/Access based tool.

....And recently had a release, announced hours ago. Congratulations to the CDC team!

Mesh4x goes mobile with JavaROSA, allows you to sync data on your handset with no Internet

2008-10-28T08:29:47-07:00

The latest batch of advances in mesh4x and JavaROSA allows you to do forms-based data input and editing on any java-enabled phone and synchronize with other phones or a server.

You can define a generic form, load the form definition to any java-enabled cell phone loaded with the JavaROSA forms clients extended with a mesh4x transport component, do data entry in your phone and synchronize the data 2-way with a server or directly peer-to-peer with another phone handset.

The form definitions are saved and exchanged as XForms, and the data as XForm models. The data can be exchanged over http (if the phone users can afford GPRS and have a data connection) or over compressed SMS messages. This can even happen between phones directly - you enter the phone number of another handset running the app and press "sync". Tondat describes this in detail in his latest blog post. The clients depicted here look awful on the emulators as they use J2ME Polish ( http://www.j2mepolish.org), which then makes the app look great on specific handset models and adapts the UI to the capabilities of each phone.

This extends the scenarios of JavaROSA- from data-entry bringing it closer to a collaboration tool, where the information being entered can be edited by multiple users and shared from a central database back to the phone in the field.

This contrasts with "data collection" pattern of data entry solutions...if you believe information is power, data collection creates a vast vacuum cleaner shifting the balance of power: away from those in the field who understand the data the best and can act on it the soonest, towards the center. But does it need to be this way?

At InSTEDD we look at information flows such as those and ask ourselves: What information should be flowing back to the field? How can the person at A work better with the person at B beyond just sending data? How do we shift from 'sending' data to sharing realtime and enriched information two ways? The mesh4x + JavaROSA effort is addresses some of these questions.

This was made possible through a collaboration and set of code contributions we had with the JavaROSA team. JavaROSA is an implementation of OpenROSA which could become a strong player in the mobile data gathering and sharing space in the near future. Kudos to Clayton Sims, Jonathan Jackson, Andreas Kollegger, and everyone else from the javaROSA team for your work and friendly attitude!

The XForm definitions are stored in an http service behind a REST API (http://sync.instedd.org/ which is a strawman of a mesh4x cloud-based service. If you played with our map-sync technology you have already used this service).

Next Steps

Our strategy with mesh4x is to contribute code to existing projects being deployed in the field that need 2-way synchronization, data exchange over SMS, or multi-master storage based on standards. Episurveyor, Gather, Pendragon etc come to mind.

Within this directive, our roadmap on mesh4x will involve effort in four areas:

Cloud Services
Data Standards
Client Applications
Transformers and Adapters

1. Cloud Services: A scalable server implementation supporting security standards . We have a skeletal solution built in C# that we grew from the 'sse' open source project in Codeplex, (which has moved to http://mesh4x.org as well). We host an instance at http://sync.instedd.org/. But it uses a relational database, so we would have to change the storage layer if we wanted to grow it for real. So what are our options? Java on EC2/S3 seems to be the shortest path given the code we already have in the project, but Python on Google App Engine sounds enticingly simple to maintain and scale, at the expense of initial effort to port the sync libraries to Python. Which seems a unnecessary until you consider that Inveneo, the African Access Point and other platforms prefer Python or Ruby for a bunch of good reasons. We'd like your input - .NET+MySQL, Java, or Python + GAE?

2. Default Data Exchange Standards: Using XForms is simple and works for easy scenarios. We'll advocate use of RDF when XForms will fall short, but by all means we wanted to avoid a custom/ad hoc way of defining a typed dictionary 'schema', versioning of that schema, and of encoding entities following the schema.

Following a clear set of standards for data formats will allow easier mapping of information from one system to another, and the creation of tools that allow end-users to define how their systems integrate.

Isn't this obvious? Defining which standards to support early in the process is critical because it is easy to reinvent the wheel in this space. Even accidentally. Anyone who can code their way out of a paper bag can define a custom way of serializing dictionaries (a collection of names and values such as name:Ed, country:Cambodia) and define a schema model for it in an hour or so. But inventing one just tends to lead to incompatibilities in the long run, and lack of interoperability in humanitarian systems is an obstacle that anyone with experience has seen get in the way of collaboration and data sharing. It is much smarter to support a well documented subset of a standard such as RDF or XForms -and define extensions as needed (both standards allow schemas/ontologies to be extended). If we can we pledge to play along, applications from multiple organizations will add up to be 'more than the sum of the parts'

3. Client Applications: We desperately would like to implement or contribute to a stand-alone fat (aka rich) client that you can use on your desktop to synchronize two data endpoints. Ideally this client would allow you to set the endpoints for synchronization, mapping of data schemas, filters, and managing conflicts - in a secure and easy-to-use interface. Any pointers?

4. Transformers and Adapters: There are many existing applications out there that do their work very well. Sometimes two applications serve similar purposes for different audiences or contexts. Sometimes new applications have to coexist with politically entrenched older systems. While we are building common-purpose adapters to mesh4x (such as Hibernate, Java RMS, and KML which we already have but also CSV and google spreadsheets for example), we already hear demand for specific adapters that take into account particular needs of real-world applications that are already deployed in the field. Which systems should we start with? We have been approached with questions about mesh4x and OpenMRS (http://openmrs.org/) or Sahana (http://www.sahana.lk/).

We'd love your input!

Phnom Penh Innovation Lab team giving its first steps!

2008-09-30T01:07:25-07:00

After months of work in the region, our technology team in Cambodia has started their daily work! We had our first standup meetings last week!

As part of InSTEDD's strategy of 'sustainable innovation' we are creating a full engineering team that over time owns and reinvents technologies used in the region. All technologies go obsolete - so for true sustainability you need to assemble a team of people that will invent the 'next thing' - and give it the skills, capital and opportunities to do so.

It's one of those rare, beautiful moments in the professional life of anyone: seeing a team's first day, the getting to know each other, starting to create a work culture, picking a set of small challenges and taking them on. Some moments stick - first standup, seeing the first code checkin notification, hearing the first idea that is "so obvious and locally appropriate yet no one in the global team had thought about it".

It starts with the people, so here they are:

From left to right we have Sopheap, Channe, (myself behind), Sodany, Laura, Saravann (below) Miguel and Tola.

Here are Mann, Channe and Sopheap

Channe Suy

I am interested working with object oriented technology such as Java and C# . Besides work, I like traveling to the mountain area or to the beach. As I start working with InSTEDD, I would like to learn more about good patterns and practices, improve communications with users, and project management.

Sopheap

I'm Sopheap, working as software developer. I am a third-year-Student at Royal university of Phnom Penh (Computer Science). I am interested in .Net and Java, and I spend my day and time on both technologies. I always do the research in the library or reading e-books and sometimes take a course related to the topic. I spent some time learning the Google technologies too. As a member of the InSTEDD Team I want to improve my ability with .Net (C#), and Java languages. Outside of work I like to spend time reading and researching, and sometimes I spend time with friends at the coffee or at the countryside with the fresh and green views.

Mann (Lim Chanmann)

My name is Lim Chanmann, but just call me Mann. I have been working on web-based application development with ASP and ASP.NET with C#. And now here at InSTEDD I am interesting in OOP, OOD, software design patterns and best practices, and project management as well as the latest technologies. I spend my free time swimming, and chatting with friends or sometimes with a stranger so I can learn something new.

The QA team and Dany in action - behind is Daniel from http://www.ideapreneur.net/, who slept over at the Lab around Barcamp Phnom Penh.(more about that soon).

Miguel Collantes (QA Manager)

I have 10 years experience in Software Quality Assurance (SQA) during which I developed management tasks and management of offshore teams. I'm working as QA Manager for InSTEDD. My challenge is to accomplish the expected goals while building and working together with foreign teams from very different cultures.

Laura Fricke Weinberg

I have 5 years experience in Software Quality Assurance (SQA) during which I developed testing tasks such as data set generation, test cases and test plans creation and QA team leadership. I am currently working with InSTEDD as QA Engineer and have great expectations in improving my scope of knowledge in QA for other InSTEDD software and technologies, as well as teaching and learning every day in our Cambodian Innovation Lab.

Saravann Paol

Hi! I am Saravann- I worked as a Computer Operator for Digital Divide Data Organization, and I got started with InSTEDD on Friday 29th August 2008, It is the first job for me that I have opportunity to work with a large team. I'm the third year student at International Institute of Cambodia (Computer Science). I am interested in my position because it can help me to learn new technologies and know more about the diseases and disasters happening in the world. These are the big problems that all the people in the world have to know and learn. I was really happy on my first day, studying with Miguel and Laura who are very good teachers, friendly and good communicators.
I hope that when I finish my studies I will have new knowledge and skills to improve my personal needs and my work.

Ung Tola

My name is Ung Tola. I worked at Digital Divide Data Organization for over two years. Now I got started with InSTEDD on September 1st 2008. I am a third-year student at Norton University and my major subject is English for Teaching. I'm also interested in the Internet and new technologies being used in the world. I am happy to spend my time with InSTEDD learning new software skills and preparing products that will be used for people helping with diseases and disasters.
In my free time I like having small picnics in the country side.

Sodany Chap

I am from Kampong Cham Province and graduated from the Royal University of Law and Economics in Law field. Then I have been pursuing my study in Masters of Management. I am very excited to have such a great opportunity to access to higher education in this competitive world, and I do wish many Cambodians had at least the same opportunity like me as education plays very important role in the social development of a country like mine.
So far, I worked and gained some experience from a few NGOs here such as Legal Aid of Cambodia (LAC), Cooperation International (CI), Cambodian Defender Project (CDP) on women trafficking, PILLAP and also from Cambodian Arts and Scholarship Foundation (CASF).
I have been working for InSTEDD since mid-June. I am extremely interested in what InSTEDD does. I am now helping with some translation and also learning to be a tester with a group of talented people from DDD and with Miquel and Laura. I have a very strong commitment to effectively and efficiently work on InSTEDD projects to ensure their smooth operation.
I'd like to deeply thank to Marry Jane, Dennis, Eduardo, Miquel and Laura and to all of others InSTEED staff who always support and encourage me in implementing my work. Also, let me wish all of them the best health, luck and success in both work and personal life.

InSTEDD has been able to attract these excellent fellows through - and with the help of- some of our partners in the region, especially Digital Divide Data and Yejj.

The goal of the QA group is to 'train the trainer' and seed a full QA unit that can carry this aspect of the software development lifecycle end to end. Cambodia has very little experience in QA and we hope to share a bit of our experience in what's needed to have robust systems deployed reliably to your users.

The development team and our Product Manager have engaged with the Cambodian Center for Disease Control and now have a prototype of a mobile application used for hotline call tracking, that then submits the information via batches of SMS messages onto a desktop with a phone plugged in, exports data to excel and posts it to an online Riff instance where the calls can be classified and collaborated on. All this is open source and was done in an agile fashion with weekly iterations and they recently refactored the code to design patterns such as MVP.

The skills gained and experience with concrete technologies (SMS-based applications, RESTful web services) will be useful beyond this particular system. Plus, Daniel Cazzulino and Nico di Tada have been giving workshops here in Phnom Penh covering topics such as REST architectures, TDD, KML and Linq.

Training, roundtables and architecture & methodology discussions are a key part of life at the InSTEDD lab. We don't have enough furniture yet to accommodate a lot of visitors but as soon as we figure out these logistics issues we'll be posting the schedule online and take an 'open house approach'- if you show up, you can participate!

PS This is just the initial team - we are still hiring for QA Engineers, Graphic Designers, Software Developers, Test Leads, Test Manager and ICT leads here in Phnom Penh. Contact me if it sounds interesting!

InSTEDD Presentation at HISA

2008-08-13T12:07:22-07:00

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.

Mesh4x SMS Adapter: Sync data without an Internet connection

2008-06-23T17:57:26-07:00

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

Improvements to Mesh4x KML adapter ("Mesh4Maps"?)

2008-05-24T01:06:16-07:00

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.

Thank you to all translation volunteers for Sahana!

2008-12-11T00:56:28-08:00

After an amazing work on behalf of the volunteers doing the translation from English to Burmese, we have translations for all Sahana strings, which will make a deployment of Sahana in the country reach a broader audience and be useful beyond the few foreign aid workers allowed in.

FlashCrowdSourcing

We've heard about crowdsourcing (e.g. as supported by Amazon's mechanical turk and other similar infrastructures) but what tools and approaches can help with flash-crowdsourcing (a flash-flood of crowds)? Volunteer management in disaster situations is a big part of relief tasks (there's even a Sahana module dedicated to that), and I wonder if we can take a bit more of advice from the 'real' world volunteer management into the 'virtual volunteer' world.

Our challenges were the need for fast coordination and high-bandwidth communication. We jumped onto Skype pretty often the first nights. It took time and false starts to figure out and describe the job well enough. I was ecstatic when the first translated line came in, and another one volunteers started explaining the task to other volunteers, and the speed picked up pretty fast.

We used Google spreadsheets to co-edit the master list of all translation batches and get a live chat amongst all volunteers, without having to agree on any IM technology. That feature by itself was great as it gave a chance for volunteers to see each others' online status and ask questions of each other. Without it, we would have been caught in the middle brokering every conversation!

The last 20% took a big chunk of the time. As we neared the end, minor issues on collisions and questions compounded with the 24-hour cycle of getting questions asked and answered from different sides of the planet.

Next steps for Sahana

Next steps that various volunteers will carry on in parallel:

Cleanup of work - fixing and editing the odd line and translation here and there
Re-encoding files- different Burmese fonts use different encodings. We chose to have faster translations at the expense of more tech work at the tail-end; which means we have to take the strings as entered by each translator in their preferred font and make it into something common. Coban Tun and other Burmese-speaking brave souls (e.g. from Burglish)are tackling the choice of fonts, encodings, and conversion tools.
Merging files - once converted the files will be able to be merged into the format required to Sahana
Test
Check-in, deploy to the Virtual Machines, which are being made available for download

If you think you can help with any of the above please let us know! And congratulations to all the translators again!

Where 2.0

2008-05-16T10:43:57-07:00

Just returned from Where 2.0, an amazing conference about "everything geo".

Robert and I went there to present some of InSTEDD's work and learn as much as we could from the geo-demigods in the event, as well as to connect with folks we had crossed paths in other forums (such as Erik Hersman - aka WhiteAfrican -pic below, of http://ushahidi.org fame).

Many folks we wanted to meet were over there and had some great dialogues about how InSTEDD approaches projects. My takeaways: communicate what we are doing more often, and have clear channels to participate in design. We are taking the feedback and this week we re-opened the InSTEDD online forums on our website and a collaborative design group for GeoChat. One of the challenges with having such a great team is that things happen fast for example, Mesh4x over 2 weeks, the KML Sync work in 5 days) and we need to consider this when working with a community of folks whose insight would make the stuff better and who could imagine new uses for the technologies.

In that spirit we started an open discussion about the direction for our technologies. The GeoChat work attracted a lot of attention. Jonathan Thompson was particularly engaged giving scenarios about position updates via Thuraya satellite phones and email. Not only he embarked with us on some interactive design there-and-then but also started contacting his buddies in the far field to ask them for feedback on the scenario. Awesome! For some reason the code in the Google Code project has fallen behind the tree we check-in to, we'll be fixing it next week.

One of the demos was about our KML Mesh4x adapter (a preview of the type of things you can do with Mesh4x). We got some good feedback on getting the versioning info embedded into the KML file, making it equally functional but more elegant. Play with it! See how you can sync one or more local maps with each other or with a cloud-based service, for example, setting up the N-way topology below (I was saving this sweet pic for another blog post but what the heck)

The morning of our talk Mikel Maron and Jesse Robbins gave a new variation their "Disaster Tech" presentation (eTech presentation from them on similar topic), and did a great job of describing the tensions that exist when high-tech stuff meets high-risk environments.

We had the honor to have our batch of talks presented by Tim O'Reilly himself. I was humbled by the reaction of the crowd to the Sahana localization to Burmese for Myanmar Nargis relief crowdsourcing effort. With the smarts, expertise, and experience in the audience, better and more efficient approaches can be invented. Here are our slides, without the associated bobbing heads:

Last but not least, this event was particularly well-put together for speakers. The O'Reilly staff was super friendly and the backstage folks very professional. I've spoken in countless events of different magnitudes, with audiences of dozens to thousands, and was positively impressed.

It's impossible to record every interaction and some things are worth blogging by themselves but hopefully this gives you an idea of what's been going on the last days.

Sahana installation poised for Myanmar disaster support

2008-05-09T22:50:57-07:00

Upon the request from Lanka software, we have successfully brought up a virtualized Sahana instance.

You can see it here: https://sahana.instedd.org

(Note you may need to ignore a certificate warning to see this until we deploy a new certificate for this server)

Learn more about Sahana at: http://sahana.lk

Juan was instrumental in getting the Debian virtualized image running well on our Red Hat host OS, thank you! The compressed Sahana VM is about 300mb, which will allow a quick re-deployment of a hardened configuration in Myanmar as necessary. I think this VM would be a good asset to keep around, allowing anyone running Windows or Linux to bring up a running Sahana server with little to no effort.

Volunteer-based Sahana localization effort

There are over 30 volunteers across 4 continents working on localizing Sahana to Burmese. We ran into multiple issues, most stemming from the lack of Unicode standardization of Burmese. We are using Google Spreadsheets to coordinate the work (the embedded live chat is an amazing feature for live coordination) and folks are using mostly MS Word to do the translations, which we accumulate on a Google Groups page. Many thanks to all involved, I'm afraid to start mentioning folks by name because I'll mess things up or miss key individuals. Jesse Robbins blogged about this in O'Reilly Radar, and Bill Behrman from Stanford has worked his rolodex though which helped us get additional volunteers. Many folks at the NetHope summit had the chance to refer folks as well. Thanks!

Google Groups for localization

Translation is hard - especially for the fonts and encodings to work together. See the awesome burglish site to see what I mean... the translated docs end up having strings like tcef;u¾rsm; which is really encoded Wwin_burmese, which would look like this with Padauk

Burglish project

One of the main issues with the localization is that it isn't just about translating strings- there is also a need to accept input in the right format. This isn't trivial with all combinations of fonts and input methods people use, and especially not trivial on a web page that has to work in multiple browsers!

There is also ongoing work on InSTEDD's GeoChat system with usual suspects and new volunteers, preparing for a potential use in Myanmar, which is topic of another blog post entirely.

Build maps collaboratively with new Mesh4x KML adapter

2008-05-08T13:08:40-07:00

A handful of months ago I met Kersten Jauer, UN Information Officer for the Central African Republic (CAR). CAR is a large country in Central Africa, surrounded by Sudan, Chad, Cameroon, Congo, and DRC; 67% of its population lives with under $1 a day and is scoured by constant internal rebellions and gender-based violence.

Kersten spends a lot of the time in the field in CAR, and put together an amazing map of the whole country to support logistics and NGO programs. Roads, provinces, bridges, fuel pumps, it all got captured by hand in Google Earth and saved as KML files. By the time I got it, Kersten's KML had grown to be 11 MB, an amazing amount of information patiently collected and edited, and periodically shared online with all those working to improve the region.

Contrast the map above showing the CAR KML with the map on the right showing the same region as seen by default in Google Earth. What got my attention was a little note in the KML:

If you would like to comment on this file or have suggestions please email to MapsAndGoogleEarth+car@hcpt.jot.com

To add a placemark just email it with a short description to the same address or kersten.jauer@undp.org

Please also check out the maps section on http://hcpt.jot.com

The map was built collaboratively, but imagine the workload Kersten must have had getting little snips, integrating them on the larger map, and then letting folks know of updates. And how would the map be maintained whenever Kersten was attending to some emergency?

Mesh4x KML Adapter

We started building a simple instance of a KML adapter for Mesh4x this week. This adapter would allow a team of people edit a KML file and then 'synchronize' it with all the others. For example, I could add a pushpin saying a bridge is down, and you could be editing another pushpin or moving it around to represent that a logistics truck has moved. When we synchronize, the truck moves around in my KML and the broken bridge appears in yours.

This could be synchronized peer-to-peer (a KML on your disk to a KML on a USB drive or someone else's box) as well as via a 'cloud' web service. Note this is changing the data inside the KML, it is not just 'file sharing'. The adapter knows about KML and keeps track of versions of fine-grained elements (pushpins, placemarks, polygons) inside the same file. It is an example of how a data mesh could be used to synchronize fine-grained data between applications.

We chose KML for this adapter as it is a standard ("OGC KML") that is widely used and supported by Google Earth (of course), Microsoft Virtual Earth, as well as nice tools that work offline and can be used in the field such as GeoPDF.

We have a sample UI (shown here) to let you play around with the basics. The effort is still on the libraries and we don't have a neat UI to let you choose endpoints or resolve conflicts, but all will come in due time. Other restrictions include having to put your placemarks in a "Shared Items" folder in your KML, and styles don't get replicated. We foresee no problems working out these constraints over the coming weeks.

To try it out, make sure you have Java installed and:

Get the sample application from http://code.google.com/p/mesh4x/downloads/list
Double click on mesh4j-KML-DemoApp.jar
Point to a KML or open the sample ones
Edit the location of Sample Pushpin 1 in File 1
Add a new pushpin in File 2
Press synchronize, and after both files should have the updated Sample pushpin 1 AND the new pushpin!

Another advantage of a data mesh is that endpoints can be heterogeneous, as long as you do the appropriate mapping. Eventually you will be able to sync a spreadsheet with columns such as Title/Description/Lat/Long into KML pushpins and back quite easily.

We hope to be showing this at Where 2.0. A lot of the team has been focusing on supporting the Myanmar disaster relief, so progress this week has been a bit random, but we still want your feedback!

Learn more about Kersten's Work in CAR at www.hdptcar.net, or get Kersten's latest epic KML.

See the Mesh4x project at http://mesh4x.org

Mesh4x adds generic database support

2008-05-06T22:45:49-07:00

First of all - a very heartfelt support to the Myanmar population in this times of crisis. Many friends are either already there or on their way to help as part of UNDAC teams. It's a tough situation in a tough context, and all my hopes reach out to the communities there so they can recover soon. Unfortunately, it won't go back to "normal" for a long time, if ever. I was in Peru last week and the August '07 earthquake still defines how people live in Pisco. The press and much of the aid has left and the town is still...leveled. Throw in a major disaster in a non-resilient environment, with a bunch of foreign aid with varied commitments to the region, and the long term outcomes are very hard to predict.

This week we made significant updates in mesh4x. One of them is a Hibernate adapter, which allows you to plug into the mesh almost any relational database available in the market

Hibernate Adapter

In our first scenario, let's say you have, or you are quickly hacking together, an application to help enter, analyze and report information. You have a database schema, and you'd like to integrate it with an excel database that field folks are using for data entry. You need to make sure updates and deletes somehow make it out to the spreadsheets, and that folks' updates make it back in. Furthermore, you'd like folks in the field to synchronize spreadsheets with each other directly - thus making it a classic mesh scenario. With the Hibernate adapter, our goal is to allow you to mesh-enable your database by just mapping your entity fields to your database fields.

Hibernate, as most developers know, is an Object-Relational Mapper library for Java. With this adapter you can now integrate into a data mesh any database engine that Hibernate supports, which is an impressive list. By supporting Hibernate as an adapter we allow every user to customize the mapping of the mesh data to their database schema using familiar tools, and get support for a lot of databases. There is still some work to do - for example, as of today the adapter still requires the database schema to revolve around the fact that the rows are being synchronized in a mesh. We expect in the upcoming weeks to remove this restriction and use two separate 'repositories', one for the synchronization information (which you shouldn't care about) and another one for your data.

This will allow you to point to almost any existing database schema and mesh it up without messing it up. (Apologies, couldn't resist).

You can always reach the project through http://mesh4x.org.

Here you can see a list of adapters and suggest your own.

Mesh4x: New Open Source Project for Data Meshes

2008-04-23T23:26:17-07:00

Today we created a new open source project to host InSTEDD's efforts on data meshes.

The goal for the project is to provide libraries, tools and applications that simplify using standards-based data meshes. Our contributions will be based on the requirements observed in global health, community development and humanitarian aid.

You can find the project here: http://code.google.com/p/mesh4x/

Our first contribution to the project consists of some libraries that implement the FeedSync specification, an open standard that describes version vectors, and processes for conflict detection and conflict preservation. FeedSync also happens to be one of the underpinnings of Microsoft's consumer-targeted Live Mesh, but could be used happily on any platform as it's based on extensions to RSS and ATOM - an obvious idea is to build a Feedsync javascript adapter for Google Gears).

Because of the project's emphasis on standards, we structured the source tree so it would host implementations in more than one platform and language. 'Mesh4x' has 2 starter source code folders - Mesh4j (Java), Mesh4n (.NET - a large C# contribution done by Clarius Labs and the Microsoft XML MVPs who already had an open source version, unit tests and all). We hope to eventually see Mesh4php, Mesh4r (Ruby) and so on.

It's a start. InSTEDD's work in SE Asia in addition to the input of humanitarian aid agencies and other providers of technology for social good will be the drivers behind our contributions. We expect work in these areas:

Adapters to different stores (e.g. MySQL, or application-specific formats, such as KML), for servers & clients, and the ETL (extract, transform, load) that goes at heterogeneous endpoints. I heard a great idea today for building open-source VMs that run on Amazon's cloud hosting.
Implementations that work on mobile devices (for example, we are currently refactoring the Java library to run in J2ME)
Support for different transports (plain XML over files, or HTTP is a start, but there are optimizations that can be done for low bandwidth, no-Internet scenarios, or integrating with a transport mesh like WASTE).
Integrating implementations with standards-based authentication and data signing approaches.
..your contributions!

Applicability for Humanitarian & Health Scenarios

So why are we at InSTEDD interested in this? Data meshes have some interesting properties:

Symmetrical: They allow data to exist in a concurrent multi-master environment where updates can be applied at any node in the mesh.
Asynchronous: They allow offline updates to information and synchronization with other nodes without requiring data locks, essential for occasionally connected applications.
Dynamic: The synchronization can happen even in constantly changing connectivity topologies. I can sync to a server and later the sync can be done between my client and another client, who could then sync with another server if the first one is there, and so on.

These properties make them very suitable for humanitarian, crisis, and health care environments, where information sharing, data system integration, and technologies that assist politically neutral solutions are beneficial. For example:

Symmetry allows you to have two audiences work on the same data through different applications, with no application being the 'master'. You can also have data sharing of sensitive information between countries or organizations with no country hosting more or less data than the other. See Mary Jane's post about the NGOs in Cambodia, to understand how important this symmetry and neutrality can be. It also allows data to move around a user independently of the device it's been created on.
Asynchronicity allows work to happen in environments where data connections are unavailable, bandwidth is low, or the only 'transport' is a USB stick.
Dynamism allows the field teams to share data amongst themselves and servers as early as possible. Unlike email, there is no need to wait for connectivity to a specific server to let the information free.

One idea could be to add data mesh capabilities to Sahana, allowing any instance running on a server or laptop to edit the information and 'sync' both ways with any other server or laptop. We have also heard scenarios where users of FrontlineSMS could synchronize information amongst themselves. If anyone is interested we'd happily work with you to see how to approach this..

Come and participate - lets share our scenarios, ideas, and code here: http://code.google.com/p/mesh4x/

SMS Applications and Microformats - lots of work to do!

2008-04-21T15:03:05-07:00

I got a comment at this weekend's Alt.Net conference - which was echoed in mikel's blog - about us not using a location microformat in the Friends Nearby and GeoChat proof of concept applications on the InSTEDD site.

In retrospect, it would have been nice to have the support for the microformat, and we should have. But it would have not -I believe- been used much, if at all.

Our bad on the omission (easy to add), but I think it would be good to explain why we did what we did, why we'd do it again (with the addition of the microformat support), and why I think a lot of usability testing is still required to make the the conversation about microformats from SMS phones more realistic.

Some background- microformats, like anything that increases interoperability and has the long-term potential of reducing user training, are pure goodness. Microformats specify ways to represent common pieces of information, such as the following for position:

l:lat,lon

...where l is a small L for location, and lat, lon are latitude and longitude. You can also add a location name like so:

l:cityname=lat,long

However in our proof of concepts we accept the following formats, and had to do some extra tricks to work with the input of the non-tech-savvy users. Here are some examples:

latlongmessage	Basic - Lat and long in decimal format with a point, a comma or any (with poor eyesight, when stressed, or in sunlight, it is easy to mix a . with a ,)
32.121 32. 121 32, 121	Weird variations of numeric input for decimal lat/longs. Spaces, commas and points all appear in unexpected spots
32.55.55 32, 55, 55	Weird variations of numeric input for Degrees Minutes Second lat/longs. Many folks had GPSs and copied what the screen showed, which by default is DMS for most devices.
Context-specific funneling e.g. 121.234 to -121.234	We call 'funneling' the act of correcting location using some encoded common sense based on context. If you are reporting fires in California, USA from a truck and suddenly your marker moves to the Yellow Sea right off China, it is quite probable you forgot the 'minus' in your longitude report. For Golden Shadow (which expected activity of people to stay in the area) we just did a blanket rule - we make everyone's location move to the USA. For Friends Nearby and future global apps, we make a hit-test for political boundaries inferred from shapefiles, and feedback to the user the inferred position 'Hope you had a nice trip to Laos' or 'Looks like you are in a plane or a boat'. This gives the user a chance to correct.
Choice of separators	We chose * instead of , ; or # as it was more accessible on all phones we tested, without needing a trip to the symbols menu in most cases.
Geocoding cities and addresses Palo Alto, CASunny! Phnom PenhKh'mim Pain-haa	In an urban setting, lat/longs are a nuisance unless you are in a flood or vectoring a helicopter. We accept addresses or town names and geo-code them using Google's gocoding APIs.
Reduce the need to report location	Assume the sender hasn't moved if no new location is submitted. Reduce the amount of times the user has to go through this complex procedure as much as you can!
Errors and omissions on the above, attempt to resolve automatically AND give a fallback for people to resolve and correct.	Loosing data and bothering the user with 'try again' is more unacceptable than trying to infer the intent of the message, so we did our best. On case of failure, add the last known good position, and log the issue so that a human could correct manually or call up and ask 'where are you?'

Where the rubber meets the road

We did a usability test with CERT volunteers and folks from the local search and rescue team. It was a diverse audience - we had in the same room a range of cell phones (from baby Nokias to Blackberrys) and the people had a range of expertise (some use their phone for email and calendar, others never used SMS before). We assumed we just had one chance to train them so we explained it once, and asked them to start sending messages. The log we got was invaluable as raw input - and informed the parsing algorithms to make them more robust for the actual exercise.

A quickie 1st hand test you can try at home: I have a collection of diverse phones to try these things out on - even phones with Khmer Script input support!. So let me see...it takes approximate 70 keystrokes to enter L:123.45,67.89 in a small Nokia, with no errors. To enter 123.45*67.89 it took me approximately 50 keystrokes. The microformat takes ~40% more key presses (and this particular phone uses the * key for the symbol pad, so that even plays against my point).

I know folks in diverse settings have tried the microformat and it works to communcate position (of course), but I'm not sure it was a representative audience of a broad set of non-tech-savvy users. The breakdown is not in the data itself, but the usability of the format.

Lessons learnt and realizing it's an ongoing effort

The key lesson for me is to make sure we accept the location microformat in addition to more user-friendly formats. If folks know the microformat beforehand (an exception rather than the norm) they can expect 'it just works'.

Alternative paths include applying machine learning feature-extraction efforts to the information, or building a smart client for rich phones that formats message for you (from the GPS?), so the user never sees the location 'wire' format at all. All approaches have pros and cons.

I am also wondering what activity is ongoing in the area of nanoformats, microformats which are slightly friendlier for numeric pad input. It's trivial to invent tiny ways of representing bits of information. The problem is that unless done right they can shift power away from the end user towards the engineers who consume that data. I don't see that as a positive power shift.

To make the effort real these nanoformats would have to get usability testing and feedback from real users in real situations to grow them into something intuitive and easy to enter in different phones.

To do that we (the 'big we') have to continue to experiment with easy to remember schemes which can be trained in one shot, can be context-specific, can be easier to discover, recall and communicate, and works even for a health volunteer who cares a lot about the content and doesn't care about the format at all.

In the end, I believe the best formats, like the best technologies, will be invisible to the end users.

If you are a geo-geek hope to see you at Where 2.0 (InSTEDD is presenting there) in a couple of weeks so we can continue the dialogue!

Off to Thailand & Cambodia

2008-03-30T02:34:42-07:00

I'm taking off to Southeast Asia in a couple of hours. Our goals for this trip is to set up the structure for our long-term presence in the region. I'm going with Dennis (our Program Director) to Bangkok to meet with many organizations that we are or would like to be working with in the area such as Mekong Basin Disease Surveillance and Mahidol. From there we go to Phnom Penh and inner Cambodia - where Mary Jane, Luke and Robert have already spent all week.

Here's my rough itinerary

March 31..April 4: Bangkok
April 4..April 15: Phnom Penh

I'd like to chat with folks who work in the technology space, especially in Cambodia. We also have a meeting with some of the folks contributing to Bar Camp Phnom Penh... So if you are in Phnom Penh and you are doing programming, web design, databases, mobile applications or program localization or have an interest in contributing tech skills to our MCP program drop me a comment here, or send an email at edjez-at-instedd-dot-org, and we'll take it from there.

See you soon!

Keeping our infrastructure 'in the cloud' and our costs close to the ground

2008-03-25T12:26:46-07:00

At InSTEDD -like at any other non-profit..or a well-run business- there is a constant evaluation of how we are using our donors' money, looking for ways we can reduce overhead and anything that doesn't translate directly into mission-related impact.

Given how much of our focus is on technology, it is natural that this concern affects how we design the infrastructure that supports our work. In this post I share the toolset we use to support the lifecycle of our technology which is effective as well as lean. Perhaps others can take advantage of the evaluation work we did or can suggest useful alternatives..

Our key requirements are:

The tools work with our Scrum+XP (eXtreme Programming) processes
The tools work for an internationally distributed team even when in the field
They are efficient cost-wise as well as adequate for the task and reliable

These requirements led us to evaluate many approaches. Ultimately, we opted for an infrastructure that requires no intranet, and no on-premise servers. That means no extra staff of acolytes & operators simply to keep the things going, and associated savings on power/heat/rackspace management...expenses decidedly not core to our mission.

I'm exaggerating. We do have an intranet. It has a printer.

By using software-as-a-service or software+services we have the advantages of lesser operations and increased reliability. We must also take a hard look at three contentious areas:

Security: Will the hosted service provide us with the level of confidentiality, transport security, and the management of user privileges that we need?
Data Portability: Will the hosted service allow us to import - and even important - EXPORT data to another service? We didn't want to fall into a lock-in scenario with 'trapped data'. Both on and off-premise backups are a must.
Accessibility: Will the service be accessible in the field? How Can it cope with low bandwidth connections? Is it possible to work offline?

In the end, we have arrived at the following list of tools that as a set fare well with our way of working and our needs. You can see the rough cost structure for the services that aren't free (When I say 'Free' I mean gratis/no cost/Free as in Beer.)

Engineering Tools:

Google Code -http://code.google.com/- We use Google Code for the source code control (SCC) of components and tools we release as FOSS . It provides issue tracking, a wiki, and downloads in addition to the source code control features. Free.

CVSDude - http://cvsdude.com/ - We host in CVSdude the source code for projects in their early stages when they aren't open source yet. Monthly fee.

Tortoise SVN - http://tortoisesvn.tigris.org/ - Tortoise is the most popular SCC client in the team. CVS & Subversion allow working offline - and managing multiple copies of the source trees on the client, and Tortoise allows you to manage these with ease. Another great feature is that we can keep in the same source tree a mix of projects hosted on Google Code and CVSDude, allowing developers to just do single update and commit operations. This helps us work on our ~~embarrassing~~ early code while keeping the open source projects up to date with no extra hassle. Monthly fee.

Fogbugz - http://www.fogbugz.com/ - We use Fogbugz for our work-item, task, and bug management. Batch updates are easy with its AJAX-based list management. It allows you to create private and shared views, exports data in multiple formats, provides email notification and reports (eg burndown charts) that are useful in agile processes. And - great for testers - it even has a client that allows you to take screenshots, annotate them, and attach them to new bugs. Finally, it has a killer feature that allows me to create new tasks by just typing and pressing "enter" ("killer" because its abuse guarantees my death at the hands of the engineering team). Monthly fee.

Virtualization - Although it is not "hosted infrastructure", virtualization saves on hardware costs. We run most of our work in virtualized environments which include including dev boxes, boxes running demos, boxes for testing or building. Some devs run these from XP, Linux, or Mac OS. We tend to use VMWare, which does a good job of allowing VPCs unfettered access to USB ports and such when working with special devices. Free or not depending on the virtualization product you use and the OSs you are hosting.

The collective annual fee of all the services listed above roughly equal the cost of one moderate-size server with no OS, no software and no support staff.

Communications & Sharing

Skype - http://www.skype.com/ - For voice, video and chat. At crunch times, our team keeps a Skype channel open -- sometimes for hours at a time. It provides a sense of literally being in the same room. We are also looking at ooVoo, vSee and N-way for video. Basic Skype is free. Additional features, such as forwarding calls to a cell phone, are very cheap.

Conference calling- http://www.intercall.com/- We chose a conference call provider that has access numbers in over 50% of the world's countries. Although costs are based on the number and location of call participants, overseas tolls are avoided, which is a significant savings on international calls.

Twitter (http://www.twitter.com) "Micro-messages" are great for ad-hoc communications, especially by SMS users spread across several countries. Within the team we send twitter direct messages by prefixing messages with d as in "d some-name I just uploaded the new version check it out". I use Twhirl as a Twitter desktop client. Free.

Sharedview - (Link) We use this new Microsoft tool for quick-and-easy screen sharing. Drawback: it only runs on Windows. But most of us have some flavor of Windows running - even if it is in a virtual machine on Linux or MacOS. Free.

Google Docs - (http://docs.google.com/) We use Google docs for taking notes and brainstorming during conference calls. It allows multiple users to collaboratively edit a document in real time. Once completed, though, we copy the document into MS Word or OneNote and save in Groove, which makes it possible to access the information offline. Free.

Groove - (Link) Microsoft Groove is useful for team coordination, managing "knowledge bases" of technologies and, most important of all, for tracking user requirements in the field. Since Groove is inherently an offline tool, it shines when Internet connectivity is an issue, but local connectivity is possible. It is not a traditional "cloud" product, but is based on a secure mesh architecture that allows pure peer-to-peer interaction. Unfortunately (hint!), it only works on the Windows OS, it speaks non-standard protocols over the wire, and has no "Web Access"/"Live" component to it. It is a part of Microsoft Office Ultimate. License Fees.

Still needing improvements...

These are some of the shortcomings with these hosted services which we hope will be addressed in the upcoming years:

Offline access: Many web-based tools would be more useful and valuable if they also offered a thoughtfully-designed, well-architected, reliable client for offline usage (and it takes more than just sprinkling Google gears around your javascript to achieve this, but that's a topic for another post).
Unified authentication - The growth in number of sites using single sign on technologies such as OpenID is encouraging but more would be better. In addition, services such as access control and other crosscutting features could be added into the mix (a trend I encouraged at an AOP panel long ago).
Support for Integration - I'd like to see more sites view themselves as 'building blocks' -- as part of a larger solution instead of trying to be the 'one stop shop'. Data, process, and UI integration APIs are always welcome.

So far this mix of products has been working well. The increase in bandwidth, along with tools and standards has allowed us to have core engineering-mission-critical tools online, and "software as/plus services" a cost-effective strategy we use everyday.

Real world results, virtual world visualizations at Life 2.0

2008-03-19T13:26:48-07:00

On Monday I attended a large presentation about visualizations at a reputable conference. NASA, NOAA, and Sun attendees were active participants. Then someone showed up dressed as a teddy bear. One of the panel members was a little blue cat. When Xantha Oe (the little blue cat) spoke, we all listened, as it explained the approaches its team had taken to visualize stock market trends -using floating shapes of volumes and colors one could fly around.

Where was all this taking place? The conference was Life 2.0 and the venue Second Life, one of the most popular virtual worlds engines and services available today. In Second Life, you get to create your virtual avatar, and given basic rules of physics and some construction tools, create buildings, clothes, vehicles..and environments where information can be visualized and played with in novel ways.

How does a conference work in Second Life?

This particular session was interesting to our work so I logged into the 'grid' on a side monitor, teleported my avatar into the conference area (I had registered as a Life 2.0 attendee before) and sat at one of the chairs in the auditorium. I turned on the video and audio streams which allowed me to hear the presentation as spoken by the panel and see the passing slides on huge screens. There is a common chat session for everyone in the area (when you 'talk' others in the amphitheater can 'hear' you). The best is that all of this infrastructure can be put together for free - an interesting approach to hold a meeting for non-profits who have tech-savvy members.

The Talk

The talk was divided into five 10-minute presentations ranging from visualizing stock prices to mathematical models and statistical analysis applied to chemistry. My key takeaways:

All visualizations basically work by consuming data in some external web service (it is possible to script Second Life objects using LSL to make HTTP calls and get/post information from arbitrary services). There was only one example of a visualization using in-world data held in "notes" - Second Life's version of a sticky note. Some visualizations consume data in proprietary stores designed to serve the required information of their particular domain (e.g. the chemistry data), but others are more general purpose and take data from RSS feeds. I found it innovative that one of the visualizations actually took a Google docs spreadsheet URL and got its data directly from there. Maybe a pattern to follow for other graphing/analysis toolkits?
Many of these visualizations are available as open source with real examples in-world of how they are used. There was at least one commercial venture building products in the area. (as the example above from Green Phosphor)
The intrinsically collaborative environment of Second Life is a good place to visualize together. I was happy to see folks paying attention to building visualizations to support conversations between multiple people and using them to lower the bar of shared understanding (as opposed to making the super-specialized visualization only one expert will consume on his/her own).
There is a growing amount of work in the area of visualization related to geography and real-world physical structures. Examples of building design and architecture were given, where layouts were optimized as a result of overlaying heatmap visualizations on virtual models of real areas (e.g. airports, highways) . One project of interest was "Second Earth" an open database of shapes and imagery that can be used to create realistic globes and maps in second life and add data on top, such as animated weather simulations. They are even working on a KML importer so you could consume in-world the same visualizations. For rigor I'll mention there are other similar efforts. This could support scenarios beyond collaborative visualization to hybrid 'augmented reality' applications where geo-tagging and field logistics blend in information from the virtual world onto images of the real world.

One thing I was sorry about is that due to a previous appointment I missed another whole session of Life 2.0 dedicated to nonprofits and humanitarian work sponsored by the MacArthur Foundation. If I can chase down one of the presenters and get a recording I'll post it here.

All in all, I'm a skeptic optimist when it comes to these applications of virtual world technology.

On one side I think it takes a lot of work to deploy useful technology in second life - especially on the perception side, explaining to the last adopter why they would ever want to learn to control an avatar, helping them beyond the perception that virtual worlds are for foolish purposes, and showing how this can be used to do work that otherwise is harder or impossible. And obviously the technologies are still maturing, adding some hurdles to the implementation. It's still hard but not frivolous.

On the other side, seeing this ongoing work and its outcomes means that the area will be constantly improving, and that there could be breakthroughs in how people visualize and understand information together. And if it's what it takes to get there, I'm willing to take the advice of a little blue cat.

BarCamp in Phnom Penh, Cambodia..and sustainable technology practices

2008-03-18T16:37:58-07:00

BarCamp is an ad-hoc gathering born from the desire for people to share and learn in an open environment. It is an intense event with discussions, demos and interaction from participants.

(From barcamp.org)

A group of enthusiasts is now organizing a BarCamp in Phnom Penh, Capital of Cambodia. Check out the website and Google groups discussions. If you are using Twitter we have a channel #BarCampPhnomPenh which you can follow here (hashtags allow you to see at a glance all 'tweets' that contain that keyword).

http://barcampphnompenh.org/

Thanks to Beth Kanter and Tharum for hookup and helping us contribute, respectively!

InSTEDD's support right now is around facilitating the conversation with technology firms who might want to sponsor the event, and finding attendees for the event. If you want to chip in contact us or jump straight into the discussion list above! Even if you can't attend, useful computer materials and sponsorship are always welcome. And of course - Can you spell "swag"?

Cambodia has a quite energetic ICT community. And as InSTEDD ramps up its work in the region we hope to become a part of it.

InSTEDD will be building a small engineering team in Phnom Penh late this year (lots of details TBD, like how we'll work with local partners in setting this up), so maybe we'll meet some candidates in the process leading up to BarCamp, too. I think that will help us build technology with sustainability in mind.

.."Sustainable technology"?

The notion of sustainability - as in sustainable agriculture, sustainable manufacturing, sustainable architecture, etc - applies to technology as well.

It is possible to throw money at a problem with the best of intentions and have very little impact in the long term, or leave things even worse than at the beginning. But one can build a structure of skills, knowledge and capital that folks can use to grow initial efforts into greater, unexpected things. Sustainable technologies can continue to exist for a longer period of time beyond an initial flurry of activity without drawing more from its environment than it gives back.

Technology ventures have many ways of becoming sustainable. From the economic sustainability perspective, for example, one way is to become a commercial product which attracts enough revenue to maintain a team that keeps the product alive and relevant to its users for enough time. Another way is to 'release' the products into open source and allow an open community influence or take over the direction. At InSTEDD we are publishing our work as open source and free services because it makes sense as a long-term strategy to serve the regions we work in. I think there's a knowledge base to be shared amongst non-profits and their beneficiaries about building and deploying technology with sustainability in mind, a library of patterns and case studies about what works and what doesn't in the long run.

I believe that being a 'good neighbor' and participating in the local IT community helps create products that work better, accelerate discovery of related local work, and provide opportunities for folks to get involved with the systems that are being used to improve their own countrywide health.

We'll be posting updates, and discussing topics that we expect will come up as BarCamp takes shape.

Hope to see you in Phnom Penh!

Hello World

2008-03-10T11:14:06-07:00

This is my first post after a blogging hiatus that started more than a year ago. Much has changed in my life between then and now so I'll make this post a quick intro of myself, and a catch up for those wondering about me dropping off the blogosphere.

At the time, I was an Architect at the Microsoft patterns & practices team, shipping content, frameworks, and tools to help folks be more productive when building large scale applications. I then became the architect with the Microsoft working on prototypes and designing approaches to foster of innovation within the company. But then...

I met Eric, InSTEDD's CEO, during Strong Angel III, a big civilian-military disaster preparedness exercise. Later in 2007 I was partnering with Robert Kirkpatrick (now in InSTEDD too), Ted Okada and Nigel Snoad from Microsoft Humanitarian Systems working on one of our prototypes that was being deployed in Afghanistan to help evolve open standards for data synchronization.

When last October InSTEDD took its current shape with Eric and Robert on board, I was presented with a great opportunity. Although I was working with smart folks across a successful company with an amazing team on pretty cool stuff, I had a longing to work in the humanitarian and health space full time. I wanted to bring in the best of technology to communities that really need it worldwide and to those who work with them. The choice was clear: I took the plunge and joined InSTEDD to lead the engineering arm, so... here I am.

Some of the things that excited me about joining InSTEDD besides the mission and the people, was how we wanted to go about things:

Contributing to disaster and health information flow by reframing it as a collaboration problem. I believe in the ability of technology to augment human capability - and its proven ability to get in the way!
The opportunity to create a field lab. Taking the notion of "If you don't go you don't know" and "design for the wild", mix it up with agile engineering to build and integrate technology so that can continuously adapt to the needs of communities.
The ability to work in a space where platforms are just a means to an end, and cross-platform interoperability part of everyday life. Our scorecard is based on improved livelihoods. We can use Linux, Google, Eclipse- you name it; contribute to stellar open source projects such as Mono or Sahana, and participate in the technical community with a strong emphasis on long term sustainability.

If you are reading this coming from the humanitarian or health space, you can infer I am a new on the block, so please be patient. I appreciate any and all guidance, feedback, recommendations, warnings, and advice you might have. If you come from the technology space, well, there is so much to be learned from what happens in the toughest environments, and I hope to share the lessons as we find them (or they find us).

Right now some of the things we are working on include:

How to develop better situational awareness of "who's doing what where" and how to use that awareness to accelerate the process of people building relationships.
How information flow can be improved "up & down": from the far field where SMS barely works to headquarters and back, with visualization and analysis, as well as between communities finding their own innovative approaches to deal with problems, and "between" the silos of human, animal, and environmental health.
How to take information typically consumed individually to create customized group collaboration environments.
What is a good mix of existing and new software, services and devices for the problems above? What is the simplest architecture that can keep it all working together in an interoperable, reliable and secure fashion?

Do any of these spark an idea? Please come and share it. It is up to us.

Eduardo Jezierski

Controlling your Privacy with Health Commons

National Health Systems as a Fabric of Services

Benefits

Example Services

Good neighbors

InSTEDD contributes the Facility Registry

Back to Rwanda

January 11th 2011

Architecture, Mobiles, and Health: 10 pitfalls

Pitfalls of an architectural approach

The landscape is improving

Recommended reading

Phones don’t change the world, people do

In the future…where are the business models?

Centralized or Distributed mobile apps? There are no ‘best’ practices…

Shared formats for data exchange

Sharing Data

The goal: An Open & Sustainable Platform for the end users

For Geeks: Progress on Mesh4x: Cloud Services, Architecture, Adapters, and Adopters

Why it matters and why InSTEDD is working on this

Cloud-Based Service

Mesh4x goes mobile with JavaROSA, allows you to sync data on your handset with no Internet

Next Steps

Phnom Penh Innovation Lab team giving its first steps!

InSTEDD Presentation at HISA

Mesh4x SMS Adapter: Sync data without an Internet connection

Scenarios

Under the hood

Next steps

References

Improvements to Mesh4x KML adapter ("Mesh4Maps"?)

Thank you to all translation volunteers for Sahana!

FlashCrowdSourcing

Next steps for Sahana

Where 2.0

Sahana installation poised for Myanmar disaster support

Volunteer-based Sahana localization effort

Build maps collaboratively with new Mesh4x KML adapter

Mesh4x KML Adapter

Mesh4x adds generic database support

Hibernate Adapter

Mesh4x: New Open Source Project for Data Meshes

Applicability for Humanitarian & Health Scenarios

SMS Applications and Microformats - lots of work to do!

Where the rubber meets the road

Lessons learnt and realizing it's an ongoing effort

Off to Thailand & Cambodia

Keeping our infrastructure 'in the cloud' and our costs close to the ground

Engineering Tools:

Communications & Sharing

Still needing improvements...

Real world results, virtual world visualizations at Life 2.0

BarCamp in Phnom Penh, Cambodia..and sustainable technology practices

Hello World