Edited by: Philip AbdelMalik, Public Health Agency of Canada, Canada
Reviewed by: Paolo D'Ancona, Istituto Superiore di Sanitá, Italy; Jeroen Van Der Meer, De Gezondheidsdienst voor Dieren, Netherlands; Ioanna Chouvarda, Aristotle University of Thessaloniki, Greece
This article was submitted to Digital Health, a section of the journal Frontiers in ICT
This is an open-access article distributed under the terms of the Creative Commons Attribution License (CC BY). The use, distribution or reproduction in other forums is permitted, provided the original author(s) and the copyright owner are credited and that the original publication in this journal is cited, in accordance with accepted academic practice. No use, distribution or reproduction is permitted which does not comply with these terms.
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,
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.,
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.
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,
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,
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.
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.
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.,
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.,
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,
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
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
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
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
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
The
The
The
The
Figure
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,
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.,
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.,
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.,
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
Subprocess depicting the detailed interview process conducted by Contact Officers. This served as a blueprint for designing the contact tracing app.
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
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,
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.,
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.
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),
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.
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.
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.