The Sahana Software Foundation participated in the most recent RELIEF experiments, which took place the third week in February in the Washington, DC area for the first time – familiarly called “Camp Roberts East” in reference to the central California location where these experiments usually take place. RELIEF – which stands for “Research and Experimentation for Local and International Emergency and First Responders – is a US Naval Postgraduate School Field Experimentation Program – that has expanded over the past couple of years to include support for humanitarian operations in collaboration with National Defense University’s Star-Tides Program.
RELIEF is an important venue for the Sahana Software Foundation because it is neutral space and is about experimentation, not evaluation. This is not an exercise. It is about innovation, cooperation, collaboration, trying new things and designing and developing solutions to commonly described problems in disaster information management. Participants are allowed to fail – something that normally can have major negative consequences for an organization in a formal exercise or evaluative environment.- but I’m glad to report that SSF continues to make breakthroughs and impress every time we attend one of these events.
RELIEF is also an important opportunity to bring together Sahana software developers, who normally do not get to work together in person to spend a significant amount of quality time together discussing requirements with stakeholder organizations, designing solutions, and working together on code.
Our team was composed of SSF Director David Bitner, Sahana Eden members Dominic König and Pat Tressel, Sahana Agasti members Glenn Pearson and Greg Miernicki, and myself. Several other members of the National Library of Medicine team who work on and with Sahana Vesuvius software also attended the hotwash (after action/lessons learned) session on Friday, including Michael Gill, George Thoma and Merwan Rodriguez.
Dominic König (center) and Pat Tressel (right) of SSF at RELIEF [James Musigo and Joram Mwangi from the University of South Alabama at left
There were two focuses to the experiments: one was on building a process for sharing geospatial data that the NGA (National Geospatial Intelligence Agency) might be willing to make available for humanitarian purposes, and the other was to look at the requirements for addressing the hospital geo-location and status challenge that was never solved for Haiti (to this day) and to design a specific solution based on everything we’ve learned thus far on how to go about doing this.
Hospital and Medical Facility Status and Location Registry
This last task was where the focus of our coding efforts was spent during the week, and we have designed an elegant solution that I believe may serve as the basis of a permanent open data repository of global health facility information – a master list if you will. While some code still needs to be written to make this operational, we plan to host and stand up a system to allow stakeholders to evaluate its value and if it gains traction, we will look to move this to a permanent public site. A separate post will describe this project in much more detail.
Other Highlights and Lessons Learned
For now, I would like to highlight and outline a number of outcomes from the four days spent at RELIEF 11-02 / Camp Robert East from 22-25 February 2011:
Situational Awareness: Lin Wells noted during the opening briefing that situational awareness should not provide a single bucket for everyone. In fact, they are trying to wean the US Department of Defense (DOD) away from the concept of the “Common Operational Picture” or COP and towards more of a user-defined operational picture. Different strokes for different folks – you should not force everyone to see the same picture. Implications for Sahana development would be customized views generated by the user (advanced user function) or pre-defined views based on user roles (simplified for the basic user).
Collaboration: One of my personal goals was to get the Eden and Agasti teams working together. This took place very organically and naturally, and some paths were found for Vesuvius to be able to consume the hospital data that Eden will be serving out. And of course, Pat did a great job at recruiting the Agasti PMC chair Greg to “do a little python”. I was also thrilled that two members of the University of South Alabama team from the Center for Strategic Health Intervention – James Musigo and Joram Mwangi – that works on the Alabama Incident Management System (AIMS) were there. They joined us in designing the hospital and health facility repository, and I think even learned a little python as well.
Translation: As part of my ongoing quest to limit duplication of efforts between our projects, we had a good internal conversation about the need to have a common translation and localization service for all Sahana software projects. Our current Pootle server has been supporting translations and localizations of Eden releases and is maintained and supported by the Eden team. One of the ways that we can expand the use of this resource and maximize its efficiency was suggested by Dominic, who proposed that a merged PO file could be created that could serve as the basis of a translation/localization for both an Eden and an Agasti release. This would eliminate the need to translate common strings for both projects (such as “First Name”, “Family Name”, Street”, “City”, “Country”, “Telephone Number”, “E-mail Address”, etc.), and maximize the use of scarce translation services.
NLM has agreed in principle to help administer and maintain the pootle server for use by Agasti; they also have access to highly-skilled translators through NLM and NIH that I hope (cue arm twisting music here) would be able to contribute translation/localization services such that both projects would benefit. We are also working on a possible donation of localization services from a global corporation to focus on providing translations and localizations of a Sahana PO file into at least the six official UN languages, plus additional local languages as identified in potential disaster-prone countries (this program to be announced soon, I hope).
This renewed focus and effort on translation and localization is needed; the experience of Project 4636 in Haiti and the success of organizing offshore volunteer translators through Crowdflower or Samasource via these organizations, as well as Crisis Commons and the individuals such as Rob Munro who organized the SEIU creole-speaking volunteers originally, is a resource we should be able to leverage in the future for emergencies and on an ongoing basis to provide translations of all Sahana releases in multiple languages.
If anyone is interested in taking the lead on this, who is not already fully or more likely over-committed to a specific Sahana project, I personally would support setting up a L10N incubator project to manage this process. Please let me know if you are interested or would like to suggest someone for this task.
Security Roles and Single Sign-On: This might be a bit away from full implementation, but we discussed the advantages of having a single-sign on between Sahana Eden and Agasti. This would simplify the use of both systems in environments where both systems might be deployed and facilitate much greater potential for interoperability and data exchange services between them, as well as being a major convenience for users. This also would likely tie nicely into the proposal to establish a global directory server, an app store, as well as mobile applications that might not be tied to either Eden or Agasti but could and would be able to send/receive data via both web services and SMS/MMS (as described in an earlier post).
In order to achieve this, it was discussed that both Eden and Agasti would have to set up similar authorization standards to address the commonality of roles – such as allowing an individual to have multiple role-assigned permissions (Eden) vs. having only one (Vesuvius). It was agreed in principle amongst those present to work towards designing a common system that would support a single-sign on (such as through OpenID) with a shared understanding of roles and permissions for users.
The standards for Sahana security need to be built out by all projects (including Mayon) on the Standards: namespace on the wiki such that it can be implemented by each project. I’ve already created a placeholder for this here and I hope that the Standards and Interoperability Committee will get involved here is facilitating the scoping of these requirements.
Product Confusion: Despite the best efforts of the strategic planning effort for the Sahana Software Foundation now underway, we were repeatedly asked to explain the difference between Eden and Agasti, to explain why we had two projects (never mind three!) that were either not totally identical in capabilities nor totally distinct from one another. I gave the standard and best answers we have for this – from the community perspective (it maximizes our volunteer pool to be able to recruit both PHP and Python programmers!) to the logical divergence of capabilities and customers (Eden is for emergency deployments, international organizations, platform for rapid development of new capabilities; Agasti a suite of applications developed to the detailed specifications of large municipality emergency management organizations with needs for high reliability, performance and scalability) to the truth (Eden is a rewrite of the original Sahana application in PHP; Agasti is continuation (and Mayon another rewrite) of the original application with some divergence of features based on specific customer needs). None of these answers seemed to satisfy, which was disheartening, to say the least.
That said, our strategic planning team is undertaking a simple language writeup to explain the different products in the Sahana Software Foundation portfolio; and we are going to use that for our marketing over the next six months or so – even if it may offend some purists out there. Sorry for that.
Ease of Deployment/Adoption: Coming out of the discussion on product differentiation is this: The truth is that Sahana customers should not care whether the system is written in PHP or Python – unless they plan to support feature development themselves (which, admittedly, many do). I have been asked from multiple potential customers of Sahana software which one they should deploy. In many cases, to me at least, the choice now is fairly obvious as Eden (especially as we are in a post-Krakatoa stage with a few distinct modules available from Vesuvius and Mayon not scheduled for a release until late in 2011) – but there has been more than one case where a combined solution might be suggested for a long-term project but the customer does not feel they can support two new platforms and has expertise in neither currently. We need to minimize the barriers to adoption if we are going to support multiple projects built on different platforms that are complex to install, deploy and support.
But Sahana software is by nature going to be complex to deploy and maintain because it is a complex data management system. It is nothing that one can download and install on a desktop on multiple platforms with a simple installer and then forget about it (though that would be a nice goal). It is somewhat the nature of FOSS and somewhat the nature of deploying a database-driven solution that is usually highly customized to local conditions. The concept for the module manager worked on during last summers GSOC and offered again for this summer’s GSOC as an app store platform that could support both Agasti and Eden is intriguing and hopefully will address some of this. An automatic updater is a nice add-on to these features as well. Tie it in with a global directory server and we’ve come a long way towards minimizing the barriers to sustainable independent deployments of Sahana software.
So, what else can the Sahana Software Foundation do to address this challenge?
- We need to offer (or work with commercial companies who can offer) hosted solutions – SAAS – as we did for the Haiti earthquake, for the Pakistan and Colombia floods, and we do for Humanity Road on an ongoing basis.
- We need to support a healthy community of commercial companies who can provide deployment, customization and maintenance and support services for customers who want to deploy Sahana software but do not feel technically capable of doing so themselves.
- We need to expand our training program to include new local partners around the world who can help support Sahana deployments.
- We need to extend our partnerships with the Standby Crisis Mappers Task Force and Crisis Commons as a means of training additional volunteers who can provide support to deployments – in times of a disaster response and especially in between disasters.
- And most importantly, we can and we must work ourselves on major enhancements towards lowering the complexity level to install and deploy Sahana software. A suggested GSOC project for Eden to migrate a lot of the configuration issues from having the manually edit a . file into one accessed through the front end admin system will be a giant step in the right direction; and I’m thrilled that my GSOC student from last summer – Shikhar Kohli – has volunteered to mentor this project idea – despite the limited amount of time I found to work with him last summer (and thanks Michael Howden for bailing me out on this).
Vesuvius!!!: I got my first good look at Sahana Vesuvius 0.9.0 release which came out about a week before RELIEF 11-02. Vesuvius provides a pretty sophisticated missing and found persons registry, designed to interface with Google Person Finder (though some work is now being done to complete round-trip updates to PF). It has a great user interface for searching and filtering records (better, honestly, than Google Person Finder), and ties into a hospital administration and triage system as well. This provides a key capability not found anywhere else – tying triage intake records that are sent ahead to hospitals for admissions purposes directly to the missing/found persons database.
This is an extremely tactical system and should be of high value to local jurisdictions. Global public repositories of missing and found persons like Google Person Finder, or the American Red Cross’s Safe & Well System, or the ICRC’s Family Links System do not address the need of local emergency responding agencies to have an intake system for missing persons reports. If there is a disaster in a large city in the developed world with an established emergency management system in place, people are going to call 911/119/111 systems; they are going to call local hospitals; and they are going to call 311 (if such a system is in place). Those responsible agencies are going to record missing person reports – they are not going to direct people to or use in the immediate aftermath a Google Person Finder, Safe & Well or Family Links site. These systems come online days later and are used for crowdsourcing community reports across vast geographic areas. Vesuvius provides such a system, where if implemented by local hospitals as it is in Bethesda, Maryland as part of the Bethesda Hospitals Emergency Preparedness Partnership (BHEPP), can serve the needs of the local emergency management authorities to care for their population.
TriagePic adds an incredible capability with incredible potential that I’m not sure even the team at NLM realizes. TriagePic allows you to take a digital photograph of a victim using a mobile device or laptop with webcam – and to enter basic identifying information about the victim and their condition (according to local medical/hospital protocols – green tag, yellow tag, red tag, grey tag, black tag). It also forwards (by e-mail) this intake record to the hospital that will be receiving the patient as well as the Lost Person registry (to identify the person as found but injured). Patient data is sent in several formats, including PFIF and XML. I see this as a tremendous asset for USAR teams, who, with minor modifications, could use such a system when pulling victims out of collapsed building. This should be built out as an Android and iPhone application as well. Vesuvius’ Lost Person Finder does have an associated iPhone application already for reporting and searching for missing and found persons.
NLM's Glenn Pearson demonstrates TriagePic and Sahana Vesuvius at RELIEF 11-02
The take a look at Vesuvius, there is a live site up which includes several test and live data sets. Please be careful as the data for Christchurch and Colombia is live. There is also a demo data set for testing. The Haiti data is located here as a historical archive. It’s all pretty impressive.
Vesuvius Christchurch Earthquake People Locator Site
Outside of local jurisdictions in the United States and developed world, international urban search and rescue teams should be interested in the capabilities of sending forward victim triage information to local health facilities and missing persons registries. There is huge potential here.
Conclusions
The Sahana Software Foundation got great value out of attending the Camp Robert East / RELIEF 11-02 experiments in Arlington, Virginia. The time together – face-time – with ourselves is invaluable, as is focused time to work on extending Sahana’s capabilities in a neutral collaborative space. The outcomes and lessons learned from this experience will endure and make us stronger as an organization and as a community.
I want to thank everyone from the Sahana community who volunteered their time and brainpower to support this event and to represent the Sahana Software Foundation so well – David, Dominic, Pat, Glenn, Greg, Mike, George, and Merwan.
We also owe a huge debt of gratitude to John Crowley, who organized the event for NDU and NPS and whose facilitation of the experiments and the planning leading up to it, and has helped keep the dream alive of finding a solution to identifying critical health facility information in a post-disaster environment – as disheartening as the Haiti experience was for all of us in this regard. Also Lin Wells for continuing to push for including open source solutions in what government looks to for solutions. Our collaborators at the University of South Alabama – James Musigo and Joram Mwangi – as well as Carl Taylor in absentia, who contributed greatly to our work during the week. I would also like to thank Cat Graham of Humanity Road who attended the event at my urging and contributed to the discussion as to the needs for the hospital and health facility system. I am hopeful that our system will become their system for tracking health facilities in all contexts. There were others who all were part of a collaborative neutral space environment that made it possible to us to be effective.
John Crowley
The Camp Roberts environment (the actual Camp Roberts – with all its kit foxes, rattlesnakes, tarantulas, lack of internet and crazy UAVs crash landing into nets) is a better suited environment than a conference room in a suburban office to replicate a disaster and emergency development environments. The next event at Camp Roberts is going to conflict with our planned annual meeting and the ISCRAM conference in Lisbon, Portugal (first announcement of that one – you heard it here first!) – but I would like to see a significant participation level by our community during the early August RELIEF event.
Let me leave you with one of Todd Huffman’s information sharing rules: give people back information as good or better than what they gave to you. That should be a central principle of what we try to achieve with Sahana software projects. Because if we can do that, there is no limit to what we can achieve.
Go forth and do good!
Like this:
Be the first to like this post.
