So the bottom line is that the city is going to be largely on its own, potentially for quite some time, after a disaster. To make matters worse large parts of the city are subject to liquefaction (think: buildings sinking into the ground) and even in areas where this isn’t an issue and the buildings have been reinforced against seismic events, the streets haven’t. So it’s quite likely that in many areas the buildings will be standing but the streets won’t. But wait, it gets worse! SF has a very transient population. The average person apparently only calls SF home for about 5 years before moving on. This means that SF doesn’t have a lot of deep community ties. So after a disaster there really aren’t existing family and neighbor relationships to fall back on. And to complicate things further SF has a reasonably large elderly and medically challenged community that have been empowered by the city to remain in their homes. But they depend on a regular supply of drugs and medical equipment to remain healthy. When the big one hits, who is going to take care of them?

None of this is news to the city of SF and it is putting in place infrastructure to try and respond. One of those program is the HUB program.

Once an emergency occurs then the anchor institutions turn themselves into Neighborhood Emergency Operation Centers (NEOCs) which have primary responsibility for collecting information about what is going on in their geographic area and routing supplies, people, etc. The hub member organizations turn into Service Providers (SPs) whom the NEOC can call upon to provide specific services ranging from food provision to medical care. Finally the block champions will form Care & Coordination Centers (CCC). This can literally be someone opening their garage or setting up in a designated park to provide a point of contact for the neighborhood. The CCCs have the most immediate responsibility to canvas their neighborhood and figure out which buildings are still standing, who is hurt, who needs food, who needs shelter, etc. The CCCs have their own supplies (tarps, basic medical supplies, etc.) but if the problem is bigger than they can handle then they need to kick the issue up to the NEOC who can use its supplies, facilities from the SPs as well as whatever emergency services (Fire, medical, etc.) that are still functional in the city to try and respond.

The good news about paper is that it’s incredibly resilient. When all else fails paper has a high probability of surviving.

The bad news about paper is that it’s slow to move, hard to handle and doesn’t update itself. It makes sharing information very challenging. For example, a CCC survey form has data that is likely to be interesting to Fire, Medical, Police, long term care, etc. But there is just one piece of paper. And moving and processing that paper in an emergency is tough.

Ideally we would just set up a cloud service to let CCCs submit data electronically and then route it as needed. But after an emergency we can’t rely on having any kind of communication infrastructure. Cell, twisted pair, coax and fiber are very likely to be down.

This is where Thali can come in.

Thali proposes using the phones in people’s pockets to let them collect and distribute information in an emergency. The city has also discussed putting phones into emergency supplies and they apparently are already putting in solar chargers. Using Thali’s peer to peer sync capabilities it becomes possible for CCCs to collect data onto phones and to use the local radios on those phones (BLE, Bluetooth, WiFi, etc.) to sync the data directly with other phones.

Using Thali it’s possible for all the data from all the volunteers in a single CCC to be put together on one device and get a global view of their immediate area. Similarly all of this data can then be sync’d up to the local NEOC who can now get a global view of its own area. Furthermore the information can be filtered and queried so it becomes possible for different experts, fire, medical, police, etc. to find the specific data they need while still having a unified data collection experience at the local level. And unlike paper, this is data that can update itself. So as new information comes in we can update the old information.

Using Thali also makes it much easier for the NEOCs to communicate with each other. Instead of handing over mountains of paper, a single device can be run over and both send and receive whatever data is available.

And best of all since Thali uses a completely dynamic ad-hoc synchronization model nothing has to be set up in advance. So the network and data can grow/shrink as the emergency progresses. And of course Thali is happy to work with the cloud so if the communication infrastructure does start working Thali can sync data up to the cloud and even relay data from parts of the city that don’t have access to those who do.

But of course, the devil is in the details.

So the thinking is that we would start with paper based forms and then make it easy to put those forms into the phones using some form of Optical Character Recognition (OCR) and Optical Mark Recognition (OMR). This would allow us to maintain the paper based forms but quickly move them into the electronic infrastructure using phone cameras to scan them.

I would also like to see if we can do anything with 802.11ah which runs on 900 Mhz. 900 Mhz can run up to a mile and uses a smaller antenna and battery draw. We already see devices using 900 MHz that provide extended range data services to phones. Using something like that we could deploy the 900 Mhz devices with the phones in emergency stores and get longer distances for less power and infrastructure. It just adds another layer of resiliency.

The guided forms issue is actually more important than it might initially appear. The forms currently used by the HUB program are fairly small because they really only focus on issues relevant to the Fire Department whose focus is on critical triage. If it isn’t burning, falling or dying then it isn’t a Fire Department issue. But in an emergency like a major earthquake we have to focus on longer term issues. Do people have their medicines? If someone needs oxygen to breath do they have power and oxygen canisters? If an elderly person is an apartment by themselves, is there debris that is going to make them fall? If people have a days worth of food, how do we get them more? To handle these issues data has to be collected, triaged and acted on. All of which results in longer forms.

So if we are going to get the data we want without overloading volunteers we are almost certainly going to end up in a two tier world. There will be a stripped down set of basic questions on the paper forms. Those will be the baseline. But for those who have the phones they will have guided forms that will allow them to collect richer sets of information and so provide better emergency response and recovery services.

In the case of Android this is pretty reasonably doable. The person who wants to get the app will need to change a security setting to allow them to side load. Then the person with the app would need to make their phone into a hotspot (this is actually something we can fully automate in the Thali app itself) and then the person who wants the app would need to connect, download the APK and then install it. Most of this can be automated and on screen instructions can handle the rest. This means we can deploy the apps to new devices in the field.

iOS, as far as I understand, is a much harder story. There is a way to side load on iOS but as far as I know it requires having a mac, a cable to the iPhone, a developer account and xCode. This all seems a bit much to me so I’m guessing we won’t worry about side loading to iOS devices.

There are two ways to potentially deal with this. One way, which Thali isn’t working on quite yet, is to allow for insecure relay. The idea is that person A can sync information to person B’s phone and then person B can sync with person C. The trick is that this can be done in a way that person B can’t access the data. This isn’t very difficult to do but it’s fragile and uses a lot of bandwidth because all the data has to be moved even if the receiver already has most of it.

One suspects we’ll need to take a different approach. Specifically, we need to allow authorized people to deputize other people. This means not just side loading the app but generating an identity and giving some level of trust to that identity. Thali already can generate the public keys and already has support for identity exchange to allow two people to securely exchange identities. What’s needed then is a way to give access rights. The idea being that those rights would only apply during the emergency and would be withdrawn when the emergency is over.

This is all doable. We have the math. But it’s going to take a bit of work to figure out all the requirements and implement them correctly.

Right now Thali focuses on mobile phones but there is no voodoo in Thali. At its heart Thali is node and that runs as well on a desktop as it down on a phone. In terms of talking with the phones, setting up an ad-hoc wifi network is easy with laptops. Just setup a hotspot and the phones can connect and sync both to the laptop and to each other (Thali supports local WiFi already). The bigger challenge will be packaging up the app to run on desktops. Right now we use Cordova and it doesn’t really have a desktop story outside of the Universal Windows Platform. But I doubt it would take much to translate a simple (e.g. no fancy plugins like, you know, Thali =) Cordova app and turn it into an a simple Node.js app that is interacted with via the browser. Ideally we would use something like Electron but we need PSK support and it isn’t in mainline node.js yet, although a PR has been submitted. But JXcore (which we currently use for Node.js on Android and iO) runs just fine on desktop too.

Step 1 - NERT Data Collection - Volunteers from NERT in a particular neighborhood (or two) will take Thali enabled disaster apps into their actual neighborhood and go to real locations with posted papers describing the contents of the building. The volunteers will ideally record that data onto paper forms that will then be read into the phones using cameras and OCR/OMR.

Step 2 - CCC - The volunteers will then go to a simulated CCC where they will sync the data on their phones with a laptop over WiFi.

Step 3 - Health & Human Services/Red Cross - At this point folks from either SF Health & Human Services and/or the Red Cross will join in. They will use the data from the NERT folks to send out their own folks in the field to collect more detailed data relevant to them (e.g. the NERT folks might identify that somebody needs medical care but the Red Cross folks would go visit the person to get the details). These folks would then go do their own data collection exercise like step 1 followed by their own sync as in step 2.

Obviously this barely touches on what Thali can do. But that’s o.k. This really and truly isn’t about Thali. We are just a small sprocket in a much larger and more important machine. This is really about showing that the computerized data entry and processing approach can work. Even more importantly, it’s meant to show that we can share data across different groups (in this case NERT and HHS/Red Cross) in order to build a clearer picture of what is going on.

There also was a lot of interest in side loading so we will probably demo that but we’ll handle it all manually just to show what can be done. We can create the automated version later.

I’m actually hoping to also bring along Ranveer Chandra from Microsoft Research. He is an expert on White Space Wi-Fi and I would love for him to do a demo of what White Space Wi-Fi can do during the drill.

Of course someone has to write the demo Thali app that will be used to make this all happen. I have zero cycles to work on the actual app, but that is where Dan’l Lewin’s civic engagement group at Microsoft comes in. The SF team, led by Scott Mauvais, is on the hook to bring in the resources to get the demo app coded up.