Tip:
Highlight text to annotate it
X
>>
JOANNE: Thanks very much for joining us today. I'm very excited to welcome our guest speakers
from InSTEDD. We have Ed Jezierski who's the vice president of engineering, and also Eric
Rasmussen. And InSTEDD, I'm sure many of you are familiar but they are a Bay Area-based
non-profit that focuses on using technology in emergency situations like, for example,
natural disasters or disease outbreaks. And Google has had a very long relationship with
InSTEDD that we're very proud of, going back to as far as 2006. So, we were actually their
first funder when they were a very new startup in Palo Alto, and we actually continued to
support their work particularly in Southeast Asia where they're working on disease surveillance
and management. And they have an innovation lab in Cambodia. But today, Ed is going to
focus on their work in Haiti right after the earthquake. They were one of the very first
organizations on the ground and they actually worked directly with search and rescue efforts
to identify survivors under the rubble and actually free those survivors, so a very exciting
effort. We're very proud of it and we're very excited to hear a little more today about
the work that they did there. So, welcome to InSTEDD.
>> JEZIERSKI: OK. Thank you. >> RASMUSSEN: Good morning, good afternoon.
It's a pleasure to be here. Thank you for the opportunity to talk. My name is Eric Rasmussen.
I'm the CEO for InSTEDD. InSTEDD, as Joanne mentioned, has a very long tradition with
Google. We were the first organization that I know of that Google spun off. We are an
independent 501(c)3. We work on two particular things; one, we work on humanitarian base
free and open source software that we have used in a number of very difficult places,
and it's for information flow when it really, really matters that information move. The
other thing we do is technical capacity building. We have the ability to teach in the developing
world with the people actually using our software and we give them the opportunity to make that
software their own. We opened our website in January of 2008. So, what we're looking
at here is about two and a half years of effort and just about two years to the week after
we opened our website, Haiti happened. And that's what we're going to talk about today.
What it means to have an Agile Technology Ethos when lives are at stake. On the 12th
of January 2010, infrastructure in Haiti effectively disappeared. Things that used to be difficult
even in the best of times became all but impossible. I have had 18 or so deployments. I worked
in Katrina; I worked in Banda Aceh; I worked in four different wars. This was the worst
I've ever seen. The numbers are a little soft. Nobody actually knows but it's something on
the order of a quarter of a million dead and about one million homeless, and about a quarter
of a million destroyed buildings, absolutely astonishing level of damage. The United Nations
was there within about 48 hours and they are in charge of most aspects of disaster response
on the international stage. We showed up very shortly afterwards. And as a consequence,
what we have here is the first humanitarian forum 2 o'clock on that Saturday, I believe,
afternoon. The earthquake had been on a Tuesday. One of the things to note here is that nobody
in the room speaks Creole. That's important. We went from that humanitarian forum meeting
back over to the Port-au-Prince airfield where we were working with the United Nation's Search
and Rescue Dispatch center. We first found our colleagues on the Icelandic search and
rescue team, and then went right next door to the adjacent tent to the UN's Search and
Rescue Dispatch center where you see in the brown hat Nico di Tada, who is an engineer
with InSTEDD, working with Map Action, an implementing partner for the office of coordinator
for humanitarian assistance for the U.N., and they are working on trying to get information
around the field to dispatch search and rescue teams just like this. There were a lot of
search and rescue teams that were on the ground by the time we got there. This is four days
after the earthquake. And we have something on the order of 50 teams. It was 56 at the
end of the search and rescue phase. You can see under USA, nine teams are there. That
is roughly one-third of the entire U.S. contingent of urban search and rescue teams. It is very
difficult to move around Port-au-Prince in the best of times when the streets are blocked
and there never were any street signs. You wind-up having to give coordinates. It turns
out that coordinates are not always latitude and longitude. MGRS is another version and
there are many, many more beyond that. Coordination of information on where things were located
was a big part of our collective problem. You also note the +88. That +88 means that
people are using satellite phones to communicate because until we got well into the first week,
there were no cell signals working efficiently in Port-au-Prince. There was some scratchy
stuff but not much. The people who were picking up folks out of the rubble were taking them
to where they could and those three hospitals I just showed were a part of it. This was
the MINUSTAH hospital. That is excellent lighting, as you can tell, within that surgical suite
because it's sunshine. We were doing this in the open air. We did more than 50 amputations
in the street because there was no heavy equipment in Haiti, and it was necessary to simply remove
limbs for people who were trapped, and it looked like this. And unfortunately, as I
mentioned, nobody spoke Creole and these people speak only Creole, so we have a bit of a problem
in communication. Health information systems were English messages written on bandages.
The people who were uninjured still had no homes to go back to so they went where they
could and established what they could for living conditions. This, as you can tell,
is in a bit of a depression. That depression was six weeks before the onset of the rainy
season. You can imagine what this looks like and you can see some of the floods that washed
away some of these camps on YouTube. Critical infrastructure includes water pumps and part
of what we saw here is the normal delivery of water which is in these water sachets.
This is ordinary for Haiti. But, ordinarily, those sachets are two cents a piece. By the
time we got there, they were 10 cents a piece which meant dehydration and hygiene were already
beginning to suffer. We found that there were people still trapped in the rubble alive when
we got there and people like this man walking to work trying to get the country back together
again, that's a working hypothesis, would hear people screaming, hear people moaning
under the rubble, and had no way to contact central authorities and needed to have a method
to do that. We also found this, that radio stations were coming back up but radios require
either the delivery of electrical outlets for power or delivery of batteries and they
were few, or running off a car which required fuel, and that was in very short supply. However,
cellphone charging system is off. So, the batteries that you see there are car batteries.
We're a common industry so we knew that we'd be able to reach people by cellphone. We went
out to find out just how the search and rescue teams were doing business, what they required
in the course of their day, we attended the same briefings that they did, and then we
got to work. This is Nico di Tada working on the Port-au-Prince airfield, and he did
not sleep for most of three days working with people all over the world. And an important
aspect of our lifeline is the red circle that you see over there. That is a BGAN satellite
terminal. We'll talk more about that in just a minute. And we also tuned in very quickly
to the cell system in Haiti itself and you can see that Nico is beginning to exchange
data in [INDISTINCT] that were working for the systems that we knew were live in Port-au-Prince.
We began to get friends with this man, Hamish Pritchard, formerly of the UK's British Antarctic
Survey team, and he was carrying messages to us. And I'm going to let Ed Jezierski,
our VP of Engineering, take over from there. Ed?
>> JEZIERSKI: Thank you, Eric. And as I transition, I wanted to talk a little bit about what was
the end result of our work in Haiti. We ended up deploying a system that allowed survivors
with cellphones to actually text in their location or whatever help they needed in whatever
form that would then get routed to CrowdFlower, who was providing crowdsource translation
and geolocation back into Thomson Reuters teams who were doing a journalistic system
for Haitians so they could get targeted messages saying, "This hospital open, this clinic open.
*** medicines are available here." All lifesaving or at least life improving information that
they need to help themselves like journalism for the survivors, and then off the RSS feeds,
et cetera, to Ushahidi as part of this Project 4636 that you might have read about, and I'll
talk about it in a second. But at the end of the day, 25,000 people were helped. Over
a million text messages were sent out in order to help them with information. And I want
to tell you a little bit about what, as an organization, we do to prepare for that. What
is the sort of work that happens before that and more importantly, what are the other works
that we're doing because InSTEDD's disaster response effort is really under 20% of what
we do. And as a Google.org grantee, we think it's important for you to hear, understand
and engage in a way that, you know, might be interesting to you and helpful to the needs
of the field. So, as Eric said, what we do is we help create, deploy and maintain technology
that's--helps in humanitarian situations. This includes public health in villages in
Southeast Asia as well as more extreme crises like Haiti with things in between like supporting
different organizations during the H1N1 crisis, helping hospitals hook up information to support
syndromic for ILI surveillance. And with the way we work is really having very small teams.
We're a very small group that goes out to the field, learns the requirements, implements
them, does a lot of design in situ to see what's really the problem that needs solving
and evolves the technologies constantly to help with the problems that we face. And Google.org
came to us three years ago--two years and a half ago with a challenge. They said, "You
know, if you choose to accept this challenge, we want you to deploy technologies that will
help national and international disease surveillance in six countries in Southeast Asia that in
a way that spans from village reporting all the way to international policymakers and
ministries of health exchanging information. Now, we were lucky because we were working
as the support of a group that was doing the international exchange of information. Think
about China, Vietnam, Laos, Cambodia deciding to share their disease numbers. These are
numbers that could change tourism figures. It's a national security to some extent. But
then, going all the way down to the field and helping with mobile phones and whatever
technology would work, the reporting of these diseases. And to give you an idea of the magnitude
of this challenge, imagine there's an organization in Cambodia right now where 10 people meet
in a room and they tell them, "We will ask you to go and help disease surveillance in
the whole of the USA. You don't speak English. You don't read English. We want you to transform
the way real time disease surveillance gets done in the USA. Now, go." And these Cambodians
get on a plane and come to the USA, right? Of course, there's some contacts, et cetera.
So, I want to tell you a lot--about the techniques that we did to design these technologies.
So as Eric mentioned, we got created in TED as a Ted Prize into 2006 by Larry Brilliant.
Immediately after that, actually in 2007, we formed the current team and we immediately
started through a phase of rapid prototyping trying on things, seeing what technologies
were out there that would help both in a crisis situations as well as doing things in two
weeks trying them out in the field. This picture over, yips, sorry, this picture over here
is from the first prototype of a tool called GeoChat. That was actually tried out in Palo
Alto search and rescue exercise operations two years ago. A lot of interaction design
experiments with it, things that tapped into Facebook data to see if that could help monitor
for diseases or get disaster teams together. We started working with the people in the
country, seeing what data was available, what sort of infrastructure they had, what data
they considered important that was up to date. You discover lots of things, for example,
poultry density maps, you know, chickens per square mile is a very important map in Southeast
Asia with all the H5N1 and avian flu risks that they have. So, you start learning these
things and how they get integrated into processes. What are the technologies they use? What is
organizations and the politics behind them? And what are the local innovators that are
really working with the skills and resources they have to improve the system. So with all
of this and working with local universities, we coalesced our first team there and started
working. And our team now is all made out of Cambodian folks and locals who are getting
training as part of the exercise. And we found many issues. The first issue is in disease
surveillance, collaboration gaps is the problem. Sometimes, somebody has to write information
about a disease outbreak happening and it doesn't go to the right person or people that
are working animal health and human health--and humans are a type of animals, so somehow,
they should be interrelated--don't work together. Different monitoring systems, different alerting
systems and we had to bridge those gaps. Also gaps in literacy and connectivity, obviously.
There was very little appropriate design. A lot of efforts come from outside, they drop
ship with a parachute--nice technology and off they go. And these things, they barely
work, they don't get used as intended. Nobody knows how to maintain them--we've seen in
villages where the clinic had solar panels that only worked for a week three years ago
and were never able to be maintained again. And the same thing happens in digital technologies.
And finally, no sustainable innovation, you know at Google how important it is to have
a culture of challenging your own assumptions and moving the ball forward and really seeing
what is the next step, right? That innovation is part of your DNA. And what we saw, there
was very little thinking about how to instantiate innovation processes in country. I mean, how
are Cambodians going to invent the next technology that is necessary in Cambodia? So, I'm going
to tell you a little bit about how we tackled these challenges. The first one--the first
set of collaboration gaps that we saw, we started tackling with the design of technologies.
Over 30% of our users, people registered in systems using things actively everyday, never
access the Internet. It's all like never, as in once a week. They never access the Internet.
Actually, they might not even probably know that a lot of the systems they are using have
cloud-based data centers behind them. They're just exchanging SMS messages with other people,
sending data into databases, receiving alerts. And the whole notion of navigating to a Web
page, also see that information is probably not there. We have huge gaps with local languages.
And we have some doodads here for you to look at afterwards. But Khmer which is a language
of Cambodia is the closest language that exists today that is close to Sanskrit, if you see
some letters here. It's not benefited from any modern organization in terms of shape
of a language, the characters, how sentence are structured. There's multiple alphabets
depending on what you want to say. And handsets that support this are not in high demand in
the market, so there's a slow adoption of handsets that let you type in SMS in your
own language. And finally, you think of a country with a lot of rural areas, a lot of
villages with small clinics and health centers like these with no electricity, no connectivity.
And who do you think requires the information the most to see what diseases need to be monitored
for and who has the best information about what is going on in the field is these people.
In a system's metaphor, they are you first sensors and they are your first and best and
fastest actuators. So they're the ones who you really want to empower with all the information
that you can and you want to bring into these collaboration systems. Right now, the challenge
is they take disease numbers in a piece of paper, it goes into a pile. That pile gets
sent to the capital city every once in a while or to the province, gets typed into a computer
system, then, it gets typed into another computer system and six months afterwards, it gains
visibility at the central level, right? And a lot of their rapid respond really happens
through the phone calls and people just trying to do an ad hoc process every time. The challenge
with that is that the right people get missed; an expert that could have contributed gets
left off. Or as we found out, phone numbers change, somebody in the field just wants to
send something to their--to the rapid response teams, they lost their address book number
or the number changed, suddenly they're out of the loop. And they get [INDISTINCT] to
get in a 4x4, later in the week and to drive and say the things personally. And these are
all the challenges that our technologies are facing. So, what we're doing to tackle it
is designing technologies in the field. So, the pictures we're showing is from visits
that we do or with our local team to discuss these requirements and these challenges in
the local language, do some rapid prototyping and implement some tools. GeoChat is one of
these tools. It's evolved over the last two years, it's a mixture of groups plus messaging
plus geo location built all together. A lot of different components you could think of
are from different tools you're familiar with. But the whole notion that somebody could send
one text message and it goes to a group of people and somebody else in that group replies
and it goes again to the whole group of people as a chat room can be really revolutionary,
as simple as it sounds, probably because it is as simple as it sounds. The notion that
we can bake in geo location from the get go into almost everything means that analysis
is simpler. And I'll tell you more about the two later. All you have seen here is a screenshot
I took just this morning, six hours ago; over in Mukdahan Province in Northern Thailand,
the jungle near the Laos border, we're sending some disease monitoring numbers. And I think,
these 246, this 5329 all relate to a number of sick people or people with a certain disease
being exchanged. And by replacing the paper systems going hierarchically with peer-to-peer
based systems that share information in the Cloud, we're making that data get to the people
who need it in a faster way. Another one of our platform technologies is RIFF and the
technologies that helped the Haiti survivors were built on RIFF. The 4636 short code you
might have seen stuff about, was sending messages that were authored in this environment where
you could, say, what are the messages that the population is sending in, categorize them,
do the translation, do some analysis in slicing and dicing to see what are the trends from
the field, what are people asking about, what are the issues they're facing, and then author
things in English, get them translated to Creole and blast them out to Geo targeted
groups and this allowed us to send messages like these, that generic health messages.
People started seeing that there were people complaining about eyes. So conjunctivitis
messages started coming out helping prevent a very rough disease. Hospitals were opening
and if you're short of trauma, pediatric et cetera, hospitals, these sort of messages
can be vital. We did an analysis with Thomson Reuters Foundation of what was the impact
of the EIS system that we were in technical support of. It was really their initiative;
we provided the geekery to them. Over 75% of people receiving these sort of messages
changed their behavior based on that. So now, instead of thinking about cell phones as a
way of reporting data and visualizing it while we're away, think about how we can use those
two-way radios essentially to give the data that can help the crowds self organize faster
and better. You know these messages went only to like, it went to under 30,000 people if
you think of over, you know, 2 million affected, it's a drop of water but it's a start of a
trend, it's the largest scale system of this sort that has ever happened and I think it
has kind of become a milestone in the history of humanitarian technology about how to involve
survivors and their mobile phones after a crises. As we go through working in the field
and doing these designs, we find additional gaps. For example, you saw these little messages
before with these numbers. Obviously, somebody's trying to report some data, won't it be good
to be able to do the feature extraction and be able to analyze that and put that into,
you know, databases for better analysis? So what we start doing is little, you know, cluster
and collection of services that helped with this, the bits and pieces, locating somebody
when they're sending a location name like Mukdahan or something like that is easy when
their sending local village names and local misspellings, it's rougher. So obviously,
we have to wait to extract those place names from their messages. And we built systems
that combine machine learning algorithms and human feedback to basically allow users train
the system how to parse information. So we went out there to the field and we tried doing
some training to send in structured data to an SMS system. And we did a very simple exercise.
We want you to report five cases of malaria and three cases of dengue. So we want you
to send M5D3. Can you do that? Can you send an SMS with M5D3? Big letters on the slide,
your item is very visible. Everybody send that. And we saw what came in. And analyzing
what came in; people send anything from common misspellings or like missing the letter by
one, separators, new lines. Expected things, all the way to somebody who just sent 53,
and we ask why did you just send 53, didn't you see like M5D3? And they were like, yes
but everybody else is sending the M and the D already so why should I pay with my credits
to send those two extra letters, right. If you try to surmount these issues, you'll have
to train a whole country right, a whole countryside in how these things work. So you really have
to make systems that adapt to their way of thinking. So Seen Tags is a pun on syntax
and is one of the systems that we built on top of GeoChat to allow people to report data
and it uses a very simple user feedback to extract the date and the numbers regardless
of which order they come in and uses some heuristics to do that. And all of this stuff
is open sourced and it can be used by anyone in their projects as well. Another huge gap,
not just reporting numbers that we found, is a gap in literacy. I mean, you're dealing
with semi-literate people, people who know how to read and write but following certain
sorts of instructions, authoring certain types of messages in mobile phones are beyond the
capability of the training. So we think that technology can help and in this case non-digital
technology. What you're looking at here is a clinician in a rural area of Cambodia who
has the task of reporting certain diseases every week to make sure that they go into
the central analysis as fast as possible. We really couldn't get them to send the syntaxes
that were necessary to report this data. So we knew some sort of aid was needed and our
platform team, Niko di Tada, working with the innovation lab team which we'll talk in
a while, started to putting together these non-electronic wheels essentially that allows
somebody in their own local language to dial in the little cutouts to the left what they
need to report and on the right they get some numbers and then they just dial in into an
IVR system, you know, and in goes the data. The smart thing about this is not just that
it's a physical device that they can hold in their hands that they can build on their
own. We are creating a website where you can enter the data that you need to report and
they will give you PDF cut and assemble instructions that you can print and put together by yourself.
The way that the data's encoded in the numbers to the right includes some error resiliency.
You'll notice that they're all prime factors basically of two primes and based on the numbers
that get reported in, we actually can tell whether they made a mistake sending the data,
whether they should have been suppose to be reporting that data, and we can even guess
with a high margin what was the data they were probably intending to send. So even if
they miss a digit, it's not like there's a very small difference between one case of
malaria or 11 cases of malaria. Here we can tell the difference and it makes for much
more accurate data from field, from locations that otherwise would not be able to report
this sort of information this fast. And here's one of our early prototypes made out of paper.
Of course, the final version has things in their local language and because it's made
out of paper, people just write other stuff on the disk for their own instructions or
reminders and so on helping them be more productive and responding to protocol better. And there's
a whole bunch of building blocks, if you're interested in the architecture behind a lot
of InSTEDD services. We work a lot with national wireless operators; we have direct DPN connections
to the people who operate the largest phone companies in Laos, Cambodia, Thailand. Sometimes
we get asked how to manage their data centers and configure their phone systems and production;
it's kind of scary in a way. But on top of their infrastructure, we have these messaging
gateways, essentially multiplexers and de-multiplexers that can work from a direct connection with
the phone company all the way down to a little phone plugged in as a modem to a computer
and bring all those messages into one soup and then route things to the different applications
appropriately. GeoChat is one of such applications and we have seen tags and other applications
coming on top of that Riff as the Haiti one and it has other applications built on top
of that. And what we're seeing now is an ecosystem of people building their own applications
on top of ours to fulfill their own needs and health. This might not sound revolutionary
to--you're like, obviously, we make platforms, you know, you make wave, you put an API on
top, you let people build their own stuff, its our way of thinking, let that innovation
that is up to fringe of your effort be taken on by your users. But how many medical record
systems do you know that you could just go and do a mash-up around and get some data
and add some functionality to? How many medical records systems do you think in low income
countries are built in a way that a very low level developer with just some PHP skills
can bring in an extent? And the answer is pretty much zero. So by actually allowing
this sort of architecture, we enabled cases like these where a local partner in Thailand,
they needed to report real-time spikes in the reporting from hospitals of people with
influenza-like symptoms, right. Before the diagnostic, just get the real-time spikes.
I'd never even--actually I have to admit I've never seen the application itself, but the
people who have seen it tell me it looks great and what it's doing is taking real-time reports
through GeoChat right, off into this custom map that using the API's, gets the data and
puts it in the database, does some very simple trend analysis and comes back with alerts
to the right Geo-coded facilities about disease alerts. And this sort of innovation if brought
into low income country health systems we think can be huge because there's a lot of
local inventiveness and also there's a lot of local passion to help improve your own
society but, you know, you don't give them something to stand on, they just have to start
from scratch and it's just too hard and this actually gets around the problem. Another
example of emergent architecture was what was done in Haiti, where all these different
building blocks now across organizations including Samasource, Ushahidi, CrowdFlower, InSTEDD,
Person Finder, Sahana just kind of came together, coordinated over real-time Skype chats with
messages coming in from this phone company going out through Nuntium, Riff, out through
RSS feeds to CrowdFlower, from there through our RSS feeds to Ushahidi, and then analyzed
by people and people typing back things in to Person Finder or Sahana as appropriate.
Nobody had planned these architecture before. And it was great that it was put together.
It helped. It saved lives. It helped things become better. I think the challenge now is
to help systematize and plan this. When you're in a crisis, you have to really put on the
blinders and say, "What is the basic things I can depend on, right?" So we have to transform
this fantastic fluke into something that is predictable, something that is systematized
where the organizations can work together and all the response agencies that need it
can rely on this in a way that's predictable. So I talked about the collaboration gaps.
I want to talk a little bit about how do we design these systems? And I just talked about
a couple of the applications we've built. I gave the metaphor of people coming to the
United States from Cambodia with a mission to improve their health information system.
In two years, make it real-time, web shared, et cetera. I challenged somebody doing that
for Obama, but never mind. And you come with your--they come with their own ideas of what
might work, what might not work--their own cultures. So does anybody who's working over
there. So if--Marco Polo when he was in his travels, he came to Africa with his own concept
about what was out there in the world. And European lore had lots of stories about, you
know, dragons and fantastic animals. And when he went to the field, he found differences
between all these things he had heard about on what was in reality. So if I told you now,
put yourself in Marco Polo's shoes and then let's say, imagine an animal with one horn
who roams the plains, right, who is huge and kind of magical in a way, nobody ever sees
them too up close, and this guys starts thinking, "Oh, wow, you know, it's a--these unicorns,
you know, sound like fantastic. I got to go see them myself." And then sees this, right?
That tells you how your own lenses, you know, what you walk with as is your own mindset
can actually change what you expect to see. Now, when you're going in to design health
information systems for low-income countries, you cannot afford to get the design wrong.
And there are many things you can do to get around it. But the first one is really a very
Zen attitude of don't expect, you know. If you're expecting, you're already one step
behind the game. And--so we use methods to actually get ahead across those barriers.
The first thing is using Agile very aggressively. We're a small team. We only have like four
developers in our platform team and four developers in our iLab team and they all use Agile practices.
You probably do here at Google as well. Our platform team uses six-week releases with
two-week iterations, XP Scrum sort of stuff. And our iLab team uses Kanban doing more real-time
prioritization of tasks. And this allows us to have a constant dialogue with our users
going back every two weeks and saying, "Is this right? Is this right? Is this right?
Is this better? A or B," right? And keep evolving the system faster because we don't know, our
users don't know, the context is changing. And to discover what works, you need that
dialogue and that constant discovery approach. We also use design techniques that allow us
to experiment with systems even before they get built. This is a picture of Channe, our
product manager in Cambodia. She is in-charge of making sure that we understand our user
requirements, doing the interaction design, rapid prototyping, and field support. And
what you're seeing here is a live exercise of something called Wizard of Oz. And somebody
had to explain Wizard of Oz to me because I hadn't seen the movie as a kid. But in the
Wizard of Oz, at the end of the whole journey to meet the wizard, they are in this big room
and there's big magical being appears and just start interacting with them and it turns
out that it's just a guy pulling strings behind the curtain. Don't pay attention to the man
behind the curtain. And what we do sometimes, to discover what applications are needed before
we ever get the chance to write one line of code, we do the same thing. We tell people
in a clinic, "Hey, you know what? We have this fantastic new system. This fantastic
new system will, if you send this text message, send you back what are the priority procedures
you have to remind your staff of to be able to detect and, you know, constrain that disease
in an earlier way." And they're like, "Oh, that sounds like a fantastic system, can I
try it?" "Oh, absolutely. Send this text message to this number and you'll see the response
or call this number and you will interact with our especially trained operator who will
be able to tell you the information." And the operator is somebody signing outside the
clinic. The system is somebody sitting in the back of the room like you are pretending
to be the system and replying with the data. And so we get the real feedback, right? It's
like, so what did you think? Is that response useful? Well, no, actually, I needed more
information about pediatrics because we work with a lot of schools here. Okay, let's do
this again. Try it again, system, more pediatrics, right? And now the message comes back with
more information around that. And in that way, pretty much in an afternoon, you can
go through a whole gamut of potential applications you could do. You could kill fast the ones
that are not applicable and get the better understanding of those which are. And the
thing is getting to what's appropriate for every level. We realize that in different
context, different things are needed. What you're see here is a live, you know, touch
screen kind of interaction with Avian Influenza tracking data from Strong Angel back in 2006
or something when these like, you know, large table touch screens were starting to become
familiar. And you've seen some VHF radios, local cellphones, and we don't come in with
a presumed idea of what works. We've chosen cell phones for some of our tools because
it is what's appropriate for them; sometimes it's SMS, sometimes its voice. Now, we're
working to see if we can integrate for domestic stuff. Some of our efforts with more VHF and
radio-based technology because that's appropriate for the local, you know, needs. So, if you
expect something to be the solution, you know, the silver bullet. If you expect something
to work in a certain way because it worked like that in other places or if you expect
the people to prefer one design over another one, you'll be surprised. So, that's why we
have to keep on our toes. And I think the last but most important aspect challenge that
we found in the field was systematizing an innovation process, an innovation culture.
How do you make people feel the ownership of the problem and give them the tools and
the capital and the skills and the connections and everything else to go and tackle those
problems? You really say, "I'm going to take my stab at this." Again, in the U.S. and in
the high-income places, you're used to the ability to that, you know that if you put
your effort to it, you could get some data about your community, get some good visualizations
and maps. And do something about your environment or your health processes that's why you probably
work here. In low-income countries, that ball still starting to--is still starting to roll.
And our approach to bridge this gap was to set up what we call an innovation lab. Two
years ago, we created a local team where working in open spaces where other people from around
the country and the region can come and collaborate, they are working everyday on distilling what
are these issues on the field. What are the simple technologies that can be built and
gaining skills in interaction design, development, quality, deployment and support to make these
technologies run. The pictures here are coming kind of rough, it's a low contrast thing but
what you don't see there is like an open space of one of our physical labs with a set of
developers working, doing technologies and applications that were demanded by local people.
They discussed the requirements in their own language. They coded them up. They deployed
them. And they're doing the support and the maintenance and evolution now. And imagine
what could happen if you could have local developers understand the basic building blocks
of these sort of systems that work in humanitarian scenarios. They know how to make SMS applications
that work at the carrier grade, right? So they could build an application that sends
two million messages per hour just like that. They know how to make mapping applications.
They know the basics of GIS. They know how to make applications that work with KML. They
know how to do basic analytics. They are not afraid of learning new languages. And actually,
we encourage that all the time saying, "Try something new, expound your boundary, you
know, just get out of that comfort zone as a way of life." And it's gone into the stage
where I love coming to the lab every time I go because they go like, "Oh Ed, by the
way, we made this application here, it's being used for this and this and that, in animal
health tracking or something. And FYI, there's like 200 people using in such province." It's
like, "Okay, awesome." And I know that it's all done by locals for locals and that this
is a sustainable long-term set of skills that exist in the country. There's another aspect
to it and what you're looking at here is a picture of a Bangladeshi woman who works for
Grameen Shakti. Grameen Shakti is an energy company, social enterprise. They make solar
products, high-efficiency clay ovens and biogas sort of products. And what they do with their
solar panel stuff is that they don't assemble the things in China just bring them and deploy
them. They bring the crates of materials, the resistors, the boards and everything.
And they train women at the village level to assemble it. A woman can walk up to a Grameen
Shakti office, walk up with a basket full of resistors and capacitors and some boards
and get some training about soldering, assemble wherever she can get electricity some of these
boards and come back and sell each one that works at 8 cents a pop. In an average day,
they can probably make around a dollar a day assembling these boards, a dollar a day puts
you above the poverty line, right? And it also means that the women have skills to maintain
and support and, you know, create their own support businesses around solar panels. Grameen
trains school girls to troubleshoot these solar panels, right? If a solar panel breaks,
they don't have to call somebody in China or get a replacement, there's a local business
somebody for a couple of dollars might help you fix your stuff. And this is a great example
of how if you push a lot of your kind of like assembly to the edge, you're creating a set
of skills that will allow others to innovate and create their own businesses and create
their own opportunities and their own social enterprises with these new found skills. And
in a way what we're doing at the iLab is similar with digital technology, right? I am sure
that at one point in time some of our iLab members will come up with this great start-up
idea and want to help society with technology and make their own organization and make a
living out of that. And that to me would be a success, right? Because it means that we're
getting the ball rolling in an ongoing way in the country. There's another form of innovation
that happens at our innovation lab helps with which is designing tools that are not just
helpful in the problems that you know about upfront but also tools that will help with
problems that you haven't yet seen. GeoChat as simple as it sounds with like it's just
chat with some feature extractions and like alerts, I mean, what's the big deal? Well,
to them the big deal is that they're used to having all these special purpose vertical
applications where somebody says, "Oh, you got to track malaria now. Here's a malaria
application. You have to use a malaria database to track in the malaria numbers. And then,
send the malaria thing to the malaria report." And then, they get this other application
saying, tuberculosis patients, get track, name, age, sex here. Oh wait, they have ***,
you have also to put them in this other database, name, age, sex there. It's a mish-mash of
technology. In one of the clinics we had, we say like, "How many patients do you see?"
"Well, we see like, I don't know, like, you know, 30, 40 everyday except Fridays." "Why
that?" "Oh, because its forms Friday, we just spend all Friday filling out the forms that
our donors and our systems require just typing things from paper into a computer." And we
try to design our systems in a way that the users can define the used cases upfront, right?
GeoChat doesn't tell you, "You should report malaria or you should report dengue." It's
not like dengue chat, whatever. We let the users come up with that and design their own
protocols and prioritize on their own. Unfortunately, that sounds logical and almost obvious to
you but it's not the way people have been exposed to technology in a lot of low-income
countries. If somebody came and told you, "Oh, what you should use email for?" Oh sometimes
I guess it could be helpful but I know at least a couple of people who could use that.
But there's a lot of local innovation, you just use a tool, you figure it out. And they're
figuring it out as on their own using these mobile applications. And here's an example
of the translated slide that shows the sort of protocols that they invent on their own
to report things. If I try to systematize this, do the H1N1 suspect case application,
it will be a lot of effort, it would be a special case, it would not withstand the winds
of time, probably after two months it would be unused. And just by creating a platform
with little add-on apps, we allow users to define these sort of things. And then, just
use the tools and adapt the apps as necessary or not. They're just like see the messages
and the need-in their conversations. Yet another way that we help the local innovation is supporting
events that do the whole network, right? We talked about our partners such as ChangeFusion
that locally build systems for these 700 hospitals in Thailand. There's a whole network of organizations
that are participating and wanting to participate in this. We've helped sponsor the first BarCamp
in Cambodia, the first BarCamp in Myanmar. And we're doing the first BarCamp in Laos,
pretty soon. So if you want to come to Vientiane, you're welcome towards the end of the year.
You know what BarCamps are, right? And as an open event that helps people bring together
and share peer to peer series of skills and knowledge, you actually accelerate innovation.
It's also great hiring grounds when we're looking for people. Whoever steps up to the
plate, just speaks at a BarCamp, probably has some of the right materials to work with
us. I want to branch on BarCamp, Rangoon specifically, because it was the largest one in the history
of the planet. We only had 6 people from abroad there. We had facilitated the organization
but the organization was done by locals and the night before, numbers of attendants had
skyrocketed between like 300 to like 3,000 on the online registration tool. We actually
thought it might be used for some sort demonstration at one point in time and we got quite worried.
Myanmar is a very closed sort of country. The government is really controls a lot of
the communications. Bloggers were asked not to congregate for a bloggers association meeting
but we were able to do BarCamp by working with organizations that had a relationship
with the government that we were able to get the message through that is dissipate for
the local economy like internal business exchange and things like that and 3,000 attendees came
through. The previous largest BarCamp was 1,000 attendees in China, no sorry, in India
and 3,000 people showed up. A BarCamp of 3,000 people is massive and that just speaks of
what is the hunger for innovation and data sharing that exist in this area. These are
some of the organizers to give you an idea and you can't see them but they're all very
happy and they're yay. Another example of user-led innovation is--we had all these community
village people exchanging messages about diseases peer to peer through GeoChat as I explained
before. When Ketsana came through and Ketsana was a large tropical storm that came through
Manila, Vietnam and Thailand, basically flooding the place, destroying houses, very high winds.
It just started sweeping through a lot of villages causing a lot of destruction and
floods. And as an example of user innovation they started using GeoChat as a way to do
peer to peer support and messaging and alerting what was going on not unlike as "There's a
storm coming fromů" because they don't have access to maybe to like the big sort of forecast
but they were with their local knowledge able to send alerts such as "This river is flooding,"
right no sensors looking at the river trust me. "This river is flooding; watch out. Tell
people to move away from it." Tell people not to stand downwind outside their houses
because the house will collapse on them and we're having a lot of injuries happen that
way or stuff that flows off the roof or from under the basement and just hits them and
this peer to peer support network was something that we didn't foresee. We knew that, you
know, having people interconnected in that reliable way would help these sort of trust
network storm but actually seeing it in action was really transformative and again, I've
always said, "If you empower people with the right tools, they have plenty of need for
this sort of communications." And finally our innovation lab in Cambodia is a multidisciplinary
team, we have program managers who are working with the accounts and they're working with
the government and with the NGOs that do like landmine picking up and that they do, you
know, like tuberculosis management and this is a picture of our library and you might
not read some, so I'm just going to tell you the sort of books that you'll find side by
side. You have "Ending Hunger", you have "Smart Mobs", you "Directory of Cambodian NGOs" and
you have the "Pragmatic Programmers", right, all books all of--all of those in the same
library. And that tells you of what sort of place the lab is, I mean have "Ending Hunger"
next to the "Pragmatic Programmer" tells you something of the sort of work that is going
on and the sort of cross disciplinary thinking that has to happen everyday where people like
challenging each other's ideas. We call ourselves a sociotechnical team because we don't know
how to describe it. We're not about technology, we're not about applied dues and we're not
just about sociology and the policy of disease surveillance. We're about changing the numbers
and making an impact. So, we haven't found a better way to describe it than that. So
essentially this is some of our work, this is how--a little bit about how we work and
what we do and I invite you to help us in ways that you think are appropriate. And want
to help--well, what you don't see very well is this is the picture of some Buddhist monks
who wanted to help us. So they came to our innovation lab and they blessed the generator
and they said we know the generator's important to you for your work, so we will bless it,
because we want you to keep doing this sort of work and that tells you, you know, you
can help from your strengths. I can tell you Google technologies are helping a lot in all
the sort of work I've shown you before. Things like Google Prediction APIs, those things
are awesome. The same thing does a lot of work as soon as we get the key approved. But
basically, they're going to save us a lot of work that otherwise we would have to start
cranking on a role and you're finding people in the universities who can like contribute
that in an open source and cheaper way. Simple things like the Google widgets, you know,
the little charts APIs, those things can help my lab in Cambodia give great interactive
applications with just, you know, some HTTP calls, and those kind of productivity boost
are really helpful. And, of course, everything with Google Earth and the Geospatial work
that you're doing is also critical for this sort of work. And that sort of building blocks,
like the Prediction API, the widgets really allow our teams to focus on the unique problems
that are found at the edge. And I think it works great as a partnership. So if you want
to learn more about like crisis response, we have some things here, examples of equipment.
For the benefit of the camera, this is one of the satellite BGAN terminals. Oops, they're
quite expensive. It's more expensive to send data through them, VHF radios, satellite phones,
that we can talk about how to--you can work on hacking your own community and its safety
processes locally or if you want to learn more about international stuff later on and
how you can help from what you do in your team already. So finally, I wanted to thank
Google.org for their support. It's been very hard work these last years in a very intense
way, but it's been, I think, a great, very innovative initiative. And in the upcoming
years, we're really excited about how to see these platforms that we've deployed and that
are being used by the thousands really snapping all those local innovation opportunities and
all that creation that can happen in the other countries in a way that really hasn't happened
in public health before and in Africa and other areas as well as Southeast Asia. So
here's my contact info, Twitter, et cetera, if you want to talk. And I think we have some
time for questions. So if we can do thatů >> Maybe just one or two.
>> JEZIERSKI: Just one or two. >> For five minutes [INDISTINCT].
>> JEZIERSKI: That's great >> You can carry on discussions.
>> JEZIERSKI: Okay, so maybe one or two questions? >> [INDISTINCT]
>> JEZIERSKI: Sure. >> Obviously fabulous work here. One number
that stuck out in my head though, you said, a million SMS messages in Haiti, tell me about
billing and what makes all the stuff go because, you know, people in--and the one guy who's
trying to shave a couple characters off his message.
>> JEZIERSKI: Well, billing, the way it works really is about partnerships with the private
sector. It's about partnership with the phone companies. In Haiti, obviously, the phone
companies knew that they were going to be part of the critical national infrastructure.
They were working 24/7. They had lost staff, they had lost facilities and antennas and
they're really working nonstop to get that cell system up. We were talking with the,
you know, CEOs and the owners and the product managers of Digicel and Voila who are the
largest organizations getting--directly getting connections into their data centers, talking
SMPP directly into their servers, working with their team everyday. They would be like,
"We have to turn the server off because we have to move the datacenter because we have
a problem with the generator and da-da-da-da." "Okay, we're off for one hour starting now.
Okay, up, now." Real-time collaboration across countries, and that sort of collaboration
at the technical level and at the commercial level is critical. In Cambodia, we have a
short code that is available nationally for GeoChat users that is free to send and free
for users to send things in and free for alerts to go out. Now, I tell you, there's a free
short code you can use to build any sort of social application in Cambodia right now.
In Laos, pretty soon, actually, it's working, but we haven't announced it. In Thailand,
it's working. And in Vietnam, pretty soon and China, the China's interesting, soů
>> That's the national government isů? >> JEZIERSKI: It's a mixture of the national
government and the phone companies really, sometimes coming in through the GSMA, sometimes
coming in through connections to the owners or through their parent companies. Ministries
of health do not have much power in low-income countries. Phone companies are more powerful.
So you have to know how to talk to them. And, actually, we have a mix of experiences at
InSTEDD including working in the private sector for many years, so we can go to a negotiating
table and talk, you know, how can you help support, I don't know, Cambodia health and,
you know, support your business at the same time. That's a sort of when we kind of help
design it. And we've done that, yeah. Any other questions? All right, thank you.