Ebola Outbreak Containment: Real-Time Task and Resource Coordination With SORMAS

1. Introduction

Outbreaks of infectious diseases such as Ebola require immediate action on control measures to avoid further spreading of the disease. High population mobility, stigmatization of people considered infectious, and fears of people who have been in contact with them require a large number of public health staff to reach out to the population. Especially contact tracing, i.e., identifying and monitoring each person who has been in contact with an infected person, is a crucial and time-intensive task for human-to-human transmittable diseases, such as Ebola. In addition to this challenge, public health staff must validate all rumors from the public about infected people.

The process of outbreak containment involves predefined measures that must be undertaken if specific criteria are fulfilled, e.g., a new case is detected, and specific data that must be collected. A widely used framework for data collection is the Integrated Disease Surveillance and Response (IDSR) framework, which provides standard surveillance forms. Managing the dynamic generation of information and coordinating all forces to execute the aforementioned tasks requires high administrational efforts. In the context of 2014's Ebola outbreak in West Africa, this was and is mainly realized via paper forms, phone calls, text messaging, and Excel sheets. This leads to a delay of knowledge transfer and corresponding countermeasures; time for the disease to spread further.

In Nigeria, the World Health Organization (WHO) was able to declare the end of the Ebola outbreak after only a few months (World Health Organization, 2014). This was possible thanks to tremendously intense and timely control measures together with beneficial circumstances surrounding case identification. At the time of the outbreak, Nigerian healthcare workers had established an Ebola reporting tool to document visits of contact people, which proved to significantly save time for information transfer (Tom-Aba et al., 2015). However, it did not address other aspects of outbreak response, e.g., case finding or bi-directional information flow.

This need is addressed by the Surveillance Outbreak Response Management System (SORMAS), whose objective is to support the existing Nigerian outbreak response mechanisms by developing a tool that provides immediate, bi-directional information exchange across all outbreak management levels. This system ensures that the most recent data is available in real-time for everyone involved in outbreak containment. SORMAS has a central data storage and provides interfaces for health workers in the field and at health centers, thus enabling them to enter information into the system and receive immediate updates from others regarding the outbreak situation. SORMAS was built in the context of an interdisciplinary cooperation between Nigerian and German public health and research institutions, which bring their respective expertise in epidemiology, IT, and hands-on experiences from the Ebola outbreak in Nigeria.

This work features the technical details of SORMAS. While the overall system idea, personas, and requirements have been presented prior, we here concentrate on the technical realization of the system (Fähnrich et al., 2015). This includes (a) the presentation of the final process models that served as blueprint for the system, (b) the underlying data model for storing and accessing surveillance data, (c) the final system architecture, and (d) the implementation details of the central part of the system: the contact tracing app.

The rest of the paper is structured as follows: Section 2 places SORMAS in context of related work. Section 3 describes our insights on outbreak containment processes in Nigeria gained during requirements engineering. We illustrate the technical aspects of SORMAS, including the epidemiological data model and architectural details. Section 4 discusses our experience and findings in setting up SORMAS in Nigeria. Section 5 concludes our work.

2. Related Work

The recent Ebola outbreak facilitated the development of new applications to support healthcare workers in their daily routines. In the following, we present systems related to SORMAS and outbreak containment in sub-Saharan Africa.

Data collection of field information, e.g., contacts and their interviews, is in parts possible via mobiles and smartphones. For example, Nigeria created customized forms with Open Data Kit (ODK) for Android phones, whilst the Ebola Care App created a distinguished app for both Android and iPhone (Ebola Care, 2014; Ibukun, 2014; Tom-Aba et al., 2015). EpiCollect enables to create custom interfaces for mobile data collection and analyses on a small scale (Aanensen et al., 2009). AfyaData uses this framework to enable an ODK-based data entry point for health workers (Karimuribo et al., 2017). CommCare as another smartphone application also supports a number of Ebola management needs, e.g., day planning (World Health Organization, 2013; Millenium Villages, 2014). EbolaTracks is an SMS-based application that supports monitoring Ebola contacts (Tracey et al., 2015). Contact persons are equipped with a mobile phone that has credit for one month. Every day, an automated service sends an SMS to the mobile phone asking for symptoms, e.g., fever or feeling sick. If the contact does not answer these SMS in time or shows symptoms, a health worker is notified for a follow-up, e.g., calling the contact person by phone. In contrast to SORMAS, these system were exclusively used for monitoring people who had made contact with Ebola cases and did not address other aspects of outbreak response, e.g., case finding or bi-directional information flow.

Case information management and outbreak analysis is in parts done via desktop computers. The Centers for Disease Control and Prevention (CDC) set up an open-source EpiInfo Viral Hemorraghic Fever (VHF) module for contact tracing (Centers for Disease Control and Prevention, 2014). It covers a range of surveillance functions such as case management, analysis and reporting. In contrast to SORMAS, the EpiInfo VHF module is not designed for bidirectional information exchange and does not address the challenge of information exchange.

The presented approaches make use of the widespread availability of mobile phones in West Africa, which allows independence from variable wire-based IT and telecommunication infrastructure. However, these systems focus on a specific use case, such as contact tracing, or a particular user group, such as healthcare workers in the field. In addition, existing solutions do not support bi-directional information exchange and especially task management to initiate the necessary control measures. With this work, we address these needs by presenting the Surveillance Outbreak Response Management System (SORMAS). Our objective is to support existing outbreak response mechanisms by providing immediate, bi-directional information exchange across all outbreak management levels, ranging from hospital informants via task supervisors to healthcare workers in the field. SORMAS has a central data storage and provides interfaces for healthcare workers in the field and at health centers, thus enabling them to enter information into the system and receive immediate updates from others regarding the outbreak situation. SORMAS also provides real-time synchronization with surveillance systems that are already used in many African countries, such as Integrated Disease Surveillance and Response (IDSR), and in its data attributes follows existing systems, such as EpiInfo.

3. Methods

In the following, we present the technical details of SORMAS. We provide an overview on the final process models derived from the requirements engineering phase, introduce the applied data schema for storing surveillance data, present the final system architecture for productive usage, and discuss implementation details of the mobile contact tracing application as the integral part of the system.

3.1. Requirement and Process Definition

We designed the system according to the procedures implemented in Nigeria during the outbreak in 2014, as those were proven to support the successful containment of Ebola. We benefited from the experiences gained from setting up the ad hoc IT infrastructure with ODK.

We identified system requirements for SORMAS in a gradual process. We used the Design Thinking methodology to systematically analyze experiences from field workers and the Ebola Emergency Operations Centre (EOC) (Plattner et al., 2014). Design Thinking involves many interviews with stakeholders to gather domain knowledge and understand the underlying processes. Those interviews are a crucial part of the overall software development process, as domain knowledge is essential to build a system that is of value for the user. Our interview partners were members of the Nigeria Field Epidemiology and Laboratory Program that provided insights into the general procedures taking place at the EOC. The interview process did not involve the collection of any private or personal information. Thus, an ethics approval was not required as per our institutions' guidelines and national regulations. An oral informed consent was obtained from all research participants, which is in line with institutional requirements.

As a first step, we defined personas and an interaction model to get a rough understanding of the system and the required components, e.g., mobile and desktop applications (Fähnrich et al., 2015). As a second step, we derived detailed process models that map the procedures of Nigerian Ebola outbreak control. The process models include all activities and responsibilities of each single participant and the flow of each data artifact produced. We refined the process models in multiple iterations involving an active exchange via e-mail, phone, and personal conversations with the field workers and staff of the EOC.

For enabling a direct discussion of the process models with our interview partners, we chose Business Process Model and Notation (BPMN 2.0) as modeling notation (Allweyer, 2010). Since it is intended as a communication medium for both business managers and technicians, team members without IT expertise can intuitively understand the notation while we remain able to discuss complex process semantics. To get direct feedback on the process models, we used an online modeling platform that allowed them to annotate the models with comments, which we then included. Figures 1, 2, 5 depict the most important parts of the process for Ebola outbreak containment in Nigeria. Due to its complexity, we encapsulated parts of the overall process, e.g., the contact tracing procedure, in subprocesses that are modeled separately. We limit the number of process models shown here to the overall process and the contact tracing; all other process models are accessible via the project website (Helmholtz Centre for Infection Research, 2016). While the detailed persona descriptions and requirements related to SORMAS have been published in previous work, we limit explanations to a minimum here to provide a rough understanding of an outbreak control process for the reader (Fähnrich et al., 2015). The overall process model in Figure 1 depicts pools for the different management teams, each working in their corresponding responsibility areas:

FIGURE 1

Figure 1. Process model of the overall process of Ebola outbreak containment in Nigeria. It splits up responsibility areas for Informants, Surveillance Management, Case Handling, and Contact Tracing teams. Further details on the highlighted activity Coordinate Contact Investigation are depicted in Figure 2.

FIGURE 2

Figure 2. Subprocess depicting details on activities for contact investigation. In general, Contact Officers have to visit contacts every day. They enter the outcome, e.g., new symptoms or not available, on the mobile device and it is immediately available to their Contact Supervisor, who is then in charge to take further action. Further details on the highlighted activity Interview Contact are depicted in Figure 5.

Informants look for rumors at health facilities and inform the Surveillance Officers. Informants are contacted if a clinician suspects an Ebola case among his patients, and they must also monitor deaths of any of the health facility staff from an acute illness. All (non-) occurrences at the hospital are summarized on a daily basis in a report that is entered into SORMAS and forwarded to the Surveillance Management Team for further action.

The Surveillance Management Team receives and seeks information directly from the community. The team maintains an overview of the current outbreak situation, investigates any new rumors, and decides whether or not to forward these to the Case Handling Team. Rumors can originate from the community, e.g., via phone calls, or from Informants.

The Case Handling Team manages all cases of Ebola disease once they receive the status suspected, which can occur either during rumor investigation or contact tracing. They are responsible for undertaking corresponding measures for caring for a case, e.g., to conduct lab tests for suspected cases, isolate confirmed cases, or organize a safe burial of deceased cases. The Case Handling Team forwards contact persons of cases to be monitored by the Contact Tracing Team.

The Contact Tracing Team traces and monitors everyone who had contact with a case. The team gets a list of contact persons from the Case Handling Team and visits everyone daily until the incubation time for Ebola has passed, i.e., 21 days, since last contact with the case. If contact persons develop symptoms in that time, they are forwarded as suspected cases to the Case Handling Team.

Except for the Informants, each team splits up into a two level hierarchy with one or more supervisors overseeing multiple officers. Supervisors have administrational duties, and assign tasks to their subordinate officers. Officers, meanwhile, execute the tasks that have been assigned to them and report the outcomes to their supervisor. Supervisors of the different teams communicate with one another, e.g., to inform each other about suspected cases.

Figure 2 depicts the process encapsulated in Figure 1's highlighted activity Coordinate Contact Investigation. Contact Supervisors are responsible for all administrational tasks; e.g., to react when a contact person is reported to be problematic, lost, released, or new. Contact Officers, on the other hand, receive a list of contacts assigned by the Contact Supervisor and must ensure that they visit each person on that list daily. If the contact constitutes a group of people, e.g., attendees of church X at date Y, each individual person must be identified first. Each contact person must be interviewed for demographic data and Ebola-specific symptoms as depicted in Figure 5. If the contact person is not available or uncooperative, Contact Officers must inform their supervisor for further action.

3.2. Data Layout

The data schema presented here was developed by epidemiologists and applied by IT experts to SORMAS. The components mainly relate to the standard surveillance forms used in Nigeria, e.g., IDSR forms. Those did not apply specifically to Ebola, though, which is why some parts of the forms were never filled out. Based on interviews with health workers and our epidemiological expertise, we used Ebola-relevant parts from the forms and extended the schema by further aspects.

The complete data schema contains entities for administration and epidemiological data. Administrative data is related to the management process, such as system users, tasks, and their assignment to staff members. Epidemiological data is related to the outbreak situation, such as all kind of cases and their contacts, places they have visited, or symptoms they have developed. This work is restricted to present the epidemiologic data schema only, as we followed common procedures for implementing user, groups, etc. for administrative data. Figure 3 depicts the epidemiologic data schema as a class diagram in Unified Modeling Language (UML) (Rumbaugh et al., 2004). The main tables are Person, Place, Case, Contact, and Rumor.

FIGURE 3

Figure 3. Data schema for capturing surveillance data in SORMAS. Each entity has a schema-wide unique ID assigned, which enables us to label every entity as rumor.

The Person table contains all static information about a person, no matter if case or contact person. Since not everyone in Nigeria owns a phone, we need to assign multiple possibilities of contacting a person, e.g., neighbors' phone numbers, which results in multiple attributes for phone numbers and descriptions. Next to the table attributes, a person is assigned an occupation, lab results, and relations to other people, e.g., relatives. The Person table also includes a link to the medical history, i.e., the Clinic table, and further to symptoms observed during visits to contact persons or clinical examinations.

The Place table contains information on places relevant to SORMAS, e.g., where a person lived, worked, or was contact traced. A place can be anything, ranging from a house in a rural area to a bus. Geolocation and PlaceDetails are required attributes because a place does not necessarily have a concrete address in Nigeria, but is rather described by “the house to the left of the huge tree 50m away from the street.” A person can stay at multiple places for a particular period of time, e.g., at church each Sunday, which is important data to track when dealing with cases and contacts. The mapping table Person2Place contains start and end dates of a person's stay.

The Case table contains information on all kinds of cases, e.g., a person who is suspected of having Ebola. A corresponding database entry contains case-specific information, e.g., the case number or symptoms onset. The attribute CaseClassification depicts the case class, e.g., suspected, lab confirmed, or discarded, whereas CaseStatus determines treatment status, e.g., under treatment, deceased, or discharged.

The Contact table contains information on every contact situation between a particular case and another person, e.g., a person having cared for an infected and sick family member at home. The table entries provide details on the concrete situation, such as the proximity to the case, since this affects the likelihood that the involved contact person becomes a case, and the date of last contact, which determines the follow-up period. However, contact situations and participating persons are typically unknown at first and must be derived from more vague descriptions, e.g., a service at church with an infected person participating. These events are captured in the ContactEvent table, whilst every person participating in that event is then later on identified via the Contact2Person table, and every contact situation is captured in the Contact table.

The Rumor table contains information about all rumors that may concern one or more cases. A rumor can be anything reported by someone; an event, a person, or a place. To link a rumor with the corresponding record in our data model, each record owns a globally unique ID. To avoid searching each table for the record a rumor refers to, the Entity table provides the link between a record and its table. The Entity table allows adding remarks to each record, which is important as information is often hidden in textual remarks, e.g., an unknown body temperature because of a lost thermometer.

3.3. System Architecture

Figure 4 depicts the final software architecture modeled in Fundamental Modeling Concepts Notation, which was applied to the SORMAS prototype (Knöpfel et al., 2006). For the implementation of the system, we follow a cloud-based approach. By using a cloud service provider, we eliminate the need for local IT management.

FIGURE 4

Figure 4. Software architecture applied to SORMAS. The system operates in the cloud and contains an in-memory computing platform that stores data securely on a server. SORMAS is divided into a desktop application for users with supervisory tasks and mobile applications for users working in the field.

Users access SORMAS via both desktop PCs and mobile devices, e.g., smartphones, where the actual access mode depends on the role of the user in the system. For example, Contact Officers working in the field access SORMAS via their mobile device, while Contact Supervisors in the Emergency Centers access it via their desktop PC. SORMAS owns a dedicated authentication layer to manage system users, e.g., Contact Officers, and their respective access rights. There exist both mobile and desktop applications depending on the user accessing the system. For example, as Contact Officers are working in the field all the time, they only access the system via a mobile app on their device, e.g., a smartphone. All data that is collected by the users is stored in an in-memory database in the cloud (Plattner, 2014).

Data security was an important requirement for our project as users collect individual and personal data. SORMAS uses latest web standards, e.g., HTTPS protocol, to encrypt all data exchange between user devices and the system. All data storages on both mobile devices and the cloud platform save their data in encrypted format. The mobile applications use standard plugins offering latest encryption strategies. The in-memory database in the cloud applies latest data security and encryption standards for a secure data storage, e.g., using Advanced Encryption Standards (AES) with 256 bit key length (Kristen et al., 2017). In addition, all access to SORMAS is handled by a central authentication platform, which coordinates users and their access rights. Only users with the corresponding login credentials and access rights are eligible to access particular data. The different personas are only allowed to see particular data that is necessary for fulfilling their distinct tasks, e.g., Surveillance Supervisors can only see rumors but not contacts, whereas Contact Supervisors can only see contacts but no rumors.

While a first version of the architecture showed dedicated desktop and mobile applications for each persona, the final prototype splits up into a desktop application and two mobile applications (Fähnrich et al., 2015). The former is meant for Surveillance, Case, and Contact Supervisors, while the latter are dedicated to Informants, Surveillance Officers, and Contact Officers. We have created one single desktop application instead of one dedicated to each supervisor persona, as it turned out that their functional requirements to the system are very similar. In addition, health workers at the emergency centers can hold more than one persona. One single desktop application enables them to switch roles via logging off and on again instead of changing to a different application. Health workers in the field do not change their roles, however; and their requirements regarding the mobile applications differ: While Contact Officers need an interview guide, Surveillance Officers need to enter rumor information. This has led to the creation of dedicated applications for Contact Officers and Informants/Surveillance Officers.

If their mobile devices have access to the Internet, the collected data will immediately be uploaded to the IMDB in the cloud and stored there. If their devices are offline, which is likely to occur in West Africa, the collected data will be stored locally in an encrypted storage and uploaded to the in-memory cloud platform as soon as Internet connection becomes available.

In the first version of the architecture, we planned on using matured software for a remote device management, e.g., for automated software updates and locking of lost devices (Fähnrich et al., 2015). It turned out, however, that the software came along with an overhead of functionality that made it rather complex for us to maintain. We therefore decided to leave it out and implement the desired functionality in the mobile applications ourselves.

3.4. Collecting Data in the Field: Contact Tracing App

The mobile application for Contact Officers allows for managing assigned contacts and their interviews. We designed it based on the process flow depicted in Figure 5. Each contact interview is considered a task for the Contact Officer. Once the app is opened and the Contact Officer has logged in with his credentials, he sees a list of all open tasks. Time-critical tasks, e.g., first visits, are highlighted by a red exclamation mark. Contact Officers can retrieve all information about their contacts stored in SORMAS, such as personal information, tracing history, related cases, and places as depicted in Figure 6. All data shown in the screenshots, e.g., person names, associated places, or symptoms, is completely fictitious and has been created by a data simulator.

FIGURE 5

Figure 5. Subprocess depicting the detailed interview process conducted by Contact Officers. This served as a blueprint for designing the contact tracing app.

FIGURE 6

Figure 6. Views of task details in the contact tracing application; from left to right: (1) general task information; (2) personal details of the contact; (3) places the contact has visited; (4) reports of former interviews; (5) associated cases.

Figure 7 shows selected views of the mobile application for a contact interview. In general, Contact Officers collect data - in particular demographic information, symptom data, and information on other contacts. Our mobile application thus guides them through the contact interview, with one question per screen. Once a question has been answered, the next question is shown on the screen, until all symptoms have been checked. When Contact Officers visit a contact for the first time, they must fill in gaps in the demographic data before they can start to check for symptoms. At the end of the interview, Contact Officers see an interview summary and are advised to schedule an appointment for the next day.

FIGURE 7

Figure 7. Views of the interview process in the contact tracing application; from left to right: (1) List of current tasks ordered by priority; (2) information provided about the task; (3) interface for entering the body temperature; (4) example question for headache; (5) appointment for next interview; (6) summary at the end of the interview; (7) interview successfully saved.

If a contact matches the Ebola case definition and thus becomes a suspected case, the mobile application shows a notification and the interview continues to record contacts of the new suspected case. For direct communication in such time-critical situations, it provides contact information, e.g., phone numbers, of all other Officers and Supervisors.

We implemented the mobile application for Contact Officers using Apache Cordova, which is a construction platform for native mobile applications using HTML, CSS, and JavaScript (Apache Software Foundation, 2014). Cordova applications can be built for mobile operating systems, such as Android, IOS, or Windows Mobile. In the scope of this project, the application is restricted to Android devices. The application runs as an AngularJS application in the mobile devices' browsers. AngularJS is a JavaScript web application framework for building HTML single-page applications; it provides a framework for Model-View-ViewModel (MVVM) architecture (Green and Seshadri, 2013). The interview is one module of the AngularJS application; it requests and forwards information from and to the application's data service. If no network is available, the app uses Cordova's storage until the content is uploaded to SORMAS' central server. Versioning conflicts during upload are resolved by a conflict management based on the following assumptions: A task can only be changed by supervisors who access the system from a desktop computer. If information on contacts changes, e.g., their symptoms or demographical data, the data from the Contact Officer is favored above all other submitters. Typically, one single Contact Officer is responsible for a contact. If a Contact Supervisor changes the data while the Contact Officer is interviewing a contact, we assume the contact and not the supervisor provides the most recent information. The content is uploaded to SORMAS' central server via a Node.js server, which receives the data from the AngularJS application. The Node.js server then handles the request by checking for authorization and data integrity and forwards corresponding database queries to SORMAS' central servers.

4. Lessons Learned During Rollout/Discussion

SORMAS was tested in a proof of concept (POC) study taking place in June and July 2015 in Oyo and Kano, Nigeria. Details on study design, setting and system implementation, i.e., application in this context, have been published separately (Adeoye et al., 2017; Moyer et al., 2017). For the study, ethical approval was obtained from the ethical committees in Kano and Oyo State. In parallel, the study was also submitted to the ethical committee of the Medical board of lower Saxony in Germany. Data confidentiality was also maintained by ensuring all computer devices for the study were secured with unique usernames and passwords. A detailed evaluation of the conducted POC study and its findings is currently prepared for publication. However, we already gained valuable experience during setting up and testing the system, which we want to share with the interested reader.

When implementing the system, especially the mobile applications, it was not possible to test them on the same devices that were used during the POC. The system itself was developed in Europe, and the mobile device markets in Europe and Africa differ greatly. Device manufacturers typically offer products with reduced features in Africa compared to Europe. From a range of devices, we confirmed one single European model with an available similar African model.

The central server must be hosted at a site with a stable power supply, which is not possible in most of Africa. For SORMAS, we hosted a server in Germany. At the same time, offline functionality for the mobile applications proved to be a crucial feature for the system's success. As in many African countries, network access via smartphone is limited in rural areas. Health workers in the field need to continue entering data, however, which requires functionality to temporarily cache the data on the mobile device for the time being offline. For immediate data transfer, a more valuable but expensive solution might have been to use satellite phones, but this was outside the project scope.

Intuitive user interfaces, well-prepared training material, and automated update processes for mobile applications are crucial for the success of a project like SORMAS. Although mobile phones are common in Nigeria, smartphones and tablets are not—at least not yet. Thus, we had to put a lot of effort into preparing the technical aspects for the rollout in Nigeria. Installation of the mobile application on each of the devices had to be prepared by a specialist. What seemed to us to be common tasks, such as installing apps from the app store, could not be done by the healthcare workers since many of them were using smartphones for the first time. Although we put emphasis on an intuitive user interface, a hands-on training for the users in advance with good documentation material proved to be essential for a successful rollout. Login and user authentication procedures commonly used in Europe proved to be impractical in the rural African context. Multiple field workers managed to enter the wrong password several times until their devices were locked by the authentication platform. It turned out that the authentication platform created too long and complex passwords for the users. To avoid this for the future, we had to manually update the mobile applications and unlock the devices, which required several days of visiting each field worker in Nigeria.

We originally designed SORMAS for handling Ebola outbreaks, i.e., the requirements were derived from experience gained in Nigeria's 2014 Ebola outbreak. However, in preparation for our POC study we noticed that it requires only few changes to SORMAS to support health workers in containing outbreaks of other diseases as well, e.g., Cholera, measles, or avian influenza (H5N1). The underlying processes and personas remain nearly the same for the different diseases, which requires no change in the actual mobile or desktop application. What differentiates the diseases is mainly the data that is collected, e.g., the types of symptoms, which requires changes in SORMAS' data model only. As the data model itself contains rather generic entities, e.g., contact, case or symptom, the changes necessary for extending SORMAS' data model to further diseases are minimal. Therefore, we extended our original scenarios tested in the POC to contain not only Ebola but also Cholera, measles and avian influenza.

5. Conclusion

In this work, we have presented the technical details of SORMAS—the Surveillance and Outbreak Response Management System. In contrast to existing approaches, this system aims to support all parties involved in outbreak containment and to enable a bi-directional information flow between them. While evaluation of the POC in Nigeria is ongoing, we expect SORMAS to improve the containment process so that health workers will be able to react faster on new and potential infections than they can with their current approach.

During our work, we experienced the importance of intensive and early involvement of users, since some seemingly obvious conditions or needs may not be ubiquitously present. The development in interdisciplinary teams, a thorough understanding of the processes, and involvement of the people who use the system are thus crucial factors for SORMAS' usability and acceptance among health workers.

As with every prototype and based on the results from the evaluation, SORMAS undergoes revision regarding its features and interfaces. Meanwhile, SORMAS has turned into an open source project with active development called SORMAS-open (Helmholtz Centre for Infection Research (HZI), 2017). This new version includes findings from our POC study and more features we had to exclude from the first version of the prototype. SORMAS-open also supports a wide range of further diseases, e.g., Lassa fever or Cholera, and is evaluated in a second field study in Nigeria.

Author Contributions

CP wrote this article and derived the process models described in this paper. Together with TL and DM, CP also supervised the technical implementation of the system. MJ was part of the implementation team and had made a significant contribution to the final pilot. KD reviewed the paper and administered the project. JB, CH, and GöK derived the data attributes and formats. JB and GöK provided valuable feedback and reviews when writing this article. SB reviewed this article and prepared evaluation sheets for test runs and the pilot in Nigeria. NS prepared the pilot for rollout in Nigeria and reviewed this article. OA and DT-A provided insights into the processes in Nigeria during Ebola outbreaks and supervised the pilot in Nigeria. GéK is the project lead of SORMAS and reviewed this article.

Funding

This project was funded by the German Ministry for Education and Research (BMBF) via the German Centre for Infection Research (DZIF) under the project title EBOKON10.

Conflict of Interest Statement

The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.

Acknowledgments

This project was an interdisciplinary effort between multiple institutions across the globe. Our thanks go to the many participants who dedicated their time and work for making this project successful: Janos Brauer, Martina Grabs, Pascal Crenzin, Arne Mayer, Dustin Gedlich, Connor Nelson, Eric Enders, Gabriele Poggensee, Sabine Mall, Celestine Ameh, Ferdinand Oyiri, Arinze Chinedu, Endie Waziri, Lisa Reigl, Maike Lamshoeft, Matthias Uflacker, and Hasso Plattner.

References

Aanensen, D. M., Huntley, D. M., Feil, E. J., and Spratt, B. G. (2009). EpiCollect: linking smartphones to web applications for epidemiology, ecology and community data collection. PLoS ONE 4:e6968. doi: 10.1371/journal.pone.0006968.

PubMed Abstract | CrossRef Full Text | Google Scholar

Adeoye, O. O., Tom-Aba, D., Ameh, C. A., Ojo, O. E., Ilori, E. A., Gidado, S. O., et al. (2017). Implementing surveillance and Outbreak Response Management and Analysis System (SORMAS) for public health in West Africa-lessons learnt and future direction. Int. J. Trop. Dis. Health 22, 1–17. doi: 10.9734/IJTDH/2017/31584

CrossRef Full Text | Google Scholar

Allweyer, T. (2010). BPMN 2.0: Introduction to the Standard for Business Process Modeling. Norderstedt: BoD–Books on Demand.

Apache Software Foundation (2014). Apache Cordova Website. Available online at: http://cordova.apache.org.

Centers for Disease Control Prevention (2014). The Epi Info Viral Hemorrhagic Fever Application. Available online at: http://epiinfovhf.codeplex.com

Ebola Care (2014). EbolaCareApp. Available online at: http://www.appsagainstebola.org/

Fähnrich, C., Denecke, K., Adeoye, O. O., Benzler, J., Claus, H., Kirchner, G., et al. (2015). Surveillance and Outbreak Response Management System (SORMAS) to support the control of the Ebola virus disease outbreak in West Africa. Euro Surveil. 20:21071. doi: 10.2807/1560-7917.ES2015.20.12.21071

CrossRef Full Text | Google Scholar

Green, B., and Seshadri, S. (2013). AngularJS. 1st Edn. Sebastopol, CA: O'Reilly Media, Inc.

Google Scholar

Helmholtz Centre for Infection Research (2016). SORMAS Project Website. Available online at: http://www.helmholtz-hzi.de/sormas

Helmholtz Centre for Infection Research (HZI) (2017). Official Website for the SORMAS Open Source Tool. Available online at: http://sormas.org/

Ibukun, Y. (2014). Nigeria Uses Android App with Facebook to Fight Ebola.

Karimuribo, E. D., Mutagahywa, E., Sindato, C., Mboera, L., Mwabukusi, M., Njenga, M. K., et al. (2017). A smartphone app (AfyaData) for innovative one health disease surveillance from community to national levels in Africa: intervention in disease surveillance. JMIR Public Health Surveill. 3:e94. doi: 10.2196/publichealth.7373

PubMed Abstract | CrossRef Full Text | Google Scholar

Knöpfel, A., Grone, B., and Tabeling, P. (2006). Fundamental Modeling Concepts: Effective Communication of IT Systems. Chichester; West Sussex: John Wiley & Sons.

Google Scholar

Kristen, A., Mack, H., and Aleksic, A. (2017). SAP HANA Security - Technical White Paper. Available online at: https://www.sap.com/documents/2016/06/3ea239ad-757c-0010-82c7-eda71af511fa.html

Millenium Villages (2014). CommCare. Available online at: http://millenniumvillages.org/videos/commcare-as-a-mobile-health-solution/.

Moyer, D., Tom-Aba, D., Sharma, S., and Krause, G. (2017). Taking Digital Innovation into the Field of Infectious Diseases: The Case of SORMAS^®, 219–236. Cham: Springer International Publishing.

Google Scholar

Plattner, H. (2014). A Course in In-Memory Data Management: The Inner Mechanics of In-Memory Databases. Berlin: Springer.

Google Scholar

Plattner, H., Meinel, C., and Leifer, L. J. (2014). Design Thinking Research: Building Innovators. Berlin: Springer.

Google Scholar

Rumbaugh, J., Jacobson, I., and Booch, G. (2004). The Unified Modeling Language Reference Manual. London: Pearson Higher Education.

Google Scholar

Tom-Aba, D., Olaleye, A., Olayinka, A. T., Nguku, P., Waziri, N., and Adewuyi, P. (2015). Innovative technological approach to Ebola virus disease outbreak response in Nigeria using the open data kit and form hub technology. PLoS ONE 10:e0131000. doi: 10.1371/journal.pone.0131000

PubMed Abstract | CrossRef Full Text | Google Scholar

Tracey, L. E., Regan, A. K., Armstrong, P. K., Dowse, G. K., and Effler, P. V. (2015). EbolaTracks: an automated SMS system for monitoring persons potentially exposed to Ebola virus disease. Eurosurveillance 20:20999. doi: 10.2807/1560-7917.ES2015.20.1.20999

CrossRef Full Text | Google Scholar

World Health Organization (2013). mHealth Alliance. Available online at: http://apps.who.int/iris/bitstream/10665/92802/1/WHO_RHR_13.18_eng.pdf

World Health Organization (WHO) (2014). Nigeria is now Free of Ebola Virus Transmission. Available online at: http://who.int/mediacentre/news/ebola/20-october-2014/en/.