In late March of 2014, the World Health Organization (WHO) reported the first cases of Ebola in the forested rural region of southeastern Guinea. These early cases marked the beginning of the West Africa Ebola epidemic, the largest in modern history.
As the months passed the number of reported cases had grown exponentially and spread to neighboring countries in Liberia and Sierra Leone and not until the summer of 2014 was the Ebola epidemic declared an international public health emergency.
The United Nations response came swiftly with the drafting and passing of a Security Council resolution that deemed the outbreak a “threat to international peace and security”. I had the pleasure of being a part of a select bunch of humanitarians tasked with drafting the resolution, getting it passed and immediately deploying to the region. Under the moniker of UNMEER (United Nations Mission of Ebola Emergency Response) we were tasked with the overall planning, coordination, and directing efforts of the UN agencies, national governments, and other humanitarian actors to the areas where they were most needed.
So how does an emergency response unit even begin to contain an outbreak of epic proportions? A person can spread the disease to others as soon as he or she begins to have symptoms; therefore, it is crucially important to identify and isolate symptomatic persons immediately and identify to whom they’ve been in contact with, in order to stop the disease from spreading. Enter “Contract Tracing”. Contact tracing is defined as the identification, assessment, and management of people who may have been exposed to a disease to prevent onward transmission.
During this outbreak, contract tracing was primarily done by a field team using antiquated paper forms that were aggregated into an electronic database at the end of the day by a data manager. The data collected helped shape the response, but you can imagine in this situation moving quickly was critical to saving lives. This paper-based system had a time-intensive effort required for entering, collating, and cleaning data creating a massive delay for decision makers! As a new student of software engineering, I’m imagining what could have been done with faster tools (such as an easily downloadable mobile application) allowing for immediate data sharing and aggregation that would shape decisions based on real-time information.
An application for field staff might include some of the following. A digital patient information form with full CRUD functionality (so records can be created, read, updated and deleted/moved (e.g. patient has a confirmed case of Ebola). The form would allow for photo capture for identification, and an additional nested form to notate all individuals the patient had contact with. Data visualization tools would display contact maps and geographic locations of confirmed cases. The application would also need to be easily adaptable as an epidemic evolves or the requirements change.
I’ll have to white board this thought process later, but am beginning to imagine the classes and schema an app of this nature would require. What would the relationships be? A Person could infect another Person. A Person could also infect many Persons. Could the InfectiousDisease itself be considered a class? A Person can infect another Person through an InfectiousDisease. One-to-many? Many-to-many? Thinking about the possible models and associations let alone the migrations I would need to run makes my head spin in the best way.
This is just one example of how developers are needed in emergency response. After 12 years of working in this sphere I’ve noticed how large organizations outsource the building of systems and spend exuberant amounts of dollars in doing so. An investment in internal software development teams just makes more sense in the context of building, upgrading and maintaining systems.
If I was to return to West Africa with the knowledge gained from my time at Flatiron School, I’d bring with me an additional perspective, which is that of a developer. I’m seeing an immense opportunity now, to engineer software to address the gaps that exist in emergency response and hope to one day have another chance at a meaningful contribution.
