| Functional requirements |
Configuration |
1 |
Accounts |
1.1 |
Configure new account |
Create a new country account and configure key options (e.g. time zone, language, theme, language, logos) within 24 hours of any new emergency or event being declared. Configuration and deployment should be simple enough to be performed rapidly by WHO epidemiologists, and not require export IT or development support. |
| Functional requirements |
Configuration |
1 |
Accounts |
1.2 |
Create organisations |
Create organisations to ensure partners are granted visibility in the system. Provide option to browse and select organizations from a global respository to uphold standardisation. |
| Functional requirements |
Configuration |
1 |
Accounts |
1.3 |
Language support |
Support internationalisation of the application, with multi-language support for entry of text strings across the system from user interface to data collection forms. |
| Functional requirements |
Configuration |
2 |
Locations |
2.1 |
Create locations |
Create a location hierarchy and store geometry for admin boundaries or lat lon coordinates for point locations. |
| Functional requirements |
Configuration |
2 |
Locations |
2.2 |
Location types |
Define location types, based on the admin levels in countries where system is operational (e.g. governorates, districts, provinces, counties) |
| Functional requirements |
Configuration |
2 |
Locations |
2.3 |
Location edits |
Manually draw location boundaries on a map to permit mapping of data collected in a poorly defined area or at community level |
| Functional requirements |
Configuration |
2 |
Locations |
2.4 |
Location import |
Create locations manually, or import from standard shp files or xls lists if there are a large number. |
| Functional requirements |
Configuration |
2 |
Locations |
2.5 |
Location groups |
Add tags to locations, to define and allow analysis by other meta data such as type of health facility, status, organisation. |
| Functional requirements |
Configuration |
2 |
Locations |
2.6 |
Location dates |
Add reporting periods to define the start/end dates for when each location is expected to report a form, to ensure completeness and timeliness calculations are accurate. |
| Functional requirements |
Configuration |
3 |
Indicators |
3.1 |
Manage indicators |
Create indicators that are appropriate for each context, and define how data should be analyzed and presented. |
| Functional requirements |
Configuration |
3 |
Indicators |
3.2 |
Indicator repository |
Provide option to browse and select indicators a global respository, to draw experience in other emergencies. |
| Functional requirements |
Configuration |
3 |
Indicators |
3.3 |
System indicators |
Provide a standardised set of system indicators to monitor core areas of performance, such as completeness, timeliness and alert management. |
| Functional requirements |
Configuration |
4 |
Users |
4.1 |
User types |
Assign different user types, based on specific user roles and needs within the application. This should control access to forms, and data, based on time and location where user is working. |
| Functional requirements |
Configuration |
4 |
Users |
4.2 |
User sign up or invitation |
Provide ability to onboard users rapidly through registration or direct invitation, so user networks can be developed quickly. |
| Functional requirements |
Early Warning and Response |
5 |
Assignments |
5.1 |
User assignments |
Define who can report what, when and from where through assignments. Let users request for admin to approve, or just give them what they need directly. |
| Functional requirements |
Early Warning and Response |
5 |
Assignments |
5.2 |
Administrator assignments |
Provide administrative level access to account or specific geographic areas in a country via user accounts. |
| Functional requirements |
Early Warning and Response |
6 |
Form manager |
6.1 |
Form manager |
Design and build forms with maximal flexibility. Must support aggregate reporting, line listing; daily or weekly frequency; health facility or higher geographic levels. Forms must deploy seamlessly across web, mobile and desktop version of the system. |
| Functional requirements |
Early Warning and Response |
6 |
Form manager |
6.2 |
Form repository |
Provide ability to browse and download forms from a global repository, or export/import from accounts, in order to use as the basis for whatever adjustments are needed according to a local context. |
| Functional requirements |
Early Warning and Response |
6 |
Form manager |
6.3 |
Form versioning |
Push updates to forms immediately to mobile users, through "over the air" (OTA) updating. Provide ability to resolve any conflicts with form versioning. |
| Functional requirements |
Early Warning and Response |
6 |
Form manager |
6.4 |
Form validation |
Set data validation rules and conditions in forms, to ensure data is as accurate as possible before it is even submitted. |
| Functional requirements |
Early Warning and Response |
6 |
Form manager |
6.5 |
Geographic reporting |
If the form requires reporting at community-level, or from a fixed site not yet entered in the system, then support reporting based on a set of lat lon coordinates. |
| Functional requirements |
Early Warning and Response |
6 |
Form manager |
6.6 |
Conditional logic |
Add conditional logic to improve data quality in forms and only show what is really necessary. |
| Functional requirements |
Early Warning and Response |
6 |
Form manager |
6.7 |
Indicator logic |
Link raw data in forms directly to indicators, to define how data will be aggregated and analyzed. |
| Functional requirements |
Early Warning and Response |
7 |
Report manager |
7.1 |
Form management |
Allow reports to be viewed, filtered, sorted, edited, deleted, commented on from a single report management interface. |
| Functional requirements |
Early Warning and Response |
7 |
Report manager |
7.2 |
Form drafts |
Provide ability to save form as a draft and continue when users has more time. |
| Functional requirements |
Early Warning and Response |
7 |
Report manager |
7.3 |
Overdue and pending reports |
Clearly display to users which reports are overdue or upcoming so they can keep track of reporting requirements. |
| Functional requirements |
Early Warning and Response |
7 |
Report manager |
7.4 |
Tracking reports |
See at a glance where reports are missing or late, at all geographic levels in a given country, to support tracking of missing reports. |
| Functional requirements |
Alert |
8 |
Alert |
8.1 |
Alert definition |
Configure alert thresholds to decide when alerts are triggered. Provide support for fixed thresholds, moving averages, variable geographic levels and minimum floors. |
| Functional requirements |
Alert |
8 |
Alert |
8.2 |
Alert notification |
If an alert threshold is exceeded, ensure a predefined group of users is immediately informed by a range of means (e.g. email, SMS or in app notifications). |
| Functional requirements |
Alert |
8 |
Alert |
8.3 |
Alert log |
View all active and closed alerts in a central alert log, in either a table or a map view. |
| Functional requirements |
Alert |
8 |
Alert |
8.4 |
Alert trend |
For any given alert, display the disease trend and any nearby alerts, in order to check for wider transmission risks. |
| Functional requirements |
Alert |
8 |
Alert |
8.5 |
Alert comments |
Provide ability to start a discussion on an alert, by adding comments that are sent directly straight back to the health facility that triggered it. |
| Functional requirements |
Alert |
8 |
Alert |
8.6 |
Alert management |
Provide common and predictable ways to manage alerts, irrespective of the source, by entering all into a standard alert management workflow. Provide ability for this to be managed on a phone for field users. |
| Functional requirements |
Alert |
8 |
Alert |
8.7 |
Alert verification |
Alerts need to be rapidly verified within 72 hours. Users should be notified and be able to complete verification at field level, including on a phone. |
| Functional requirements |
Alert |
8 |
Alert |
8.8 |
Alert risk assessment |
Provide rapid response teams with ability to conduct indepth risk assessment of each alert, including recording of hazard, exposure and context assessment data. Again all on the phone. |
| Functional requirements |
Alert |
8 |
Alert |
8.9 |
Alert investigation |
If further investigation is needed as part of the risk assessment (for example, laboratory test to confirm the cause) then provide ablity to append the investigation reports to the specific alert. |
| Functional requirements |
Alert |
8 |
Alert |
8.10 |
Alert risk characterisation |
Assign a final level of risk to each alert, based on a risk matrix that takes into consideration likeilhood and consequences to derive a final risk outcome. |
| Functional requirements |
Alert |
8 |
Alert |
8.11 |
Alert outcome |
Add the final outcome for each alert and decide if an outbreak response is needed. |
| Functional requirements |
Alert |
8 |
Alert |
8.12 |
Alert reactivation |
Allow alerts to be montiored or discarded at anytime. If more information comes to light and they need to be reactivated quickly and simply. |
| Functional requirements |
Alert |
9 |
Laboratory |
9.1 |
Laboratory surveillance |
Provide restricted access so forms containing laboratory data can only be entered by lab users. When lab results are available, provide immediate feedback to teams in the field, so they can act accordingly based on the result. |
| Functional requirements |
Data analysis |
10 |
Data analysis |
10.1 |
Data export |
Allow approved users to export data per form, or for a selection of indicators, to allow customised analysis in other statistical software (e.g. SPSS, STATA and R). |
| Functional requirements |
Data analysis |
10 |
Data analysis |
10.2 |
Data redaction |
Ensure data confidentiality and data privacy when patient-level data is collected, by allowing any identifying fields (such as name, address) to be redacted and prevented from being published or exported. Or allow export to be turned off altogether for specific forms. |
| Functional requirements |
Data analysis |
10 |
Data analysis |
10.3 |
Data analysis |
Allow raw data in forms to be linked to indicators, and then visualised in a rich range of analysis outputs (e.g. Chloropleth maps, Heat maps, treemaps, chloropleth maps, box and whisker plots, circle plots, scatter plots). |
| Functional requirements |
Data analysis |
10 |
Data analysis |
10.4 |
Dashboards |
Allow dashboards to be configured to show key indicators at a glance, in full screen, when users log into the application |
| Functional requirements |
Data analysis |
10 |
Data analysis |
10.5 |
Templates |
Set up rich html templates for regular information products (e.g. weekly epidemiological bulletins) and publish automatically to pdf when needed. |
| Functional requirements |
System management |
11 |
System management |
11.1 |
Activity feed |
View at a glance all user activity in one place. |
| Functional requirements |
System management |
11 |
System management |
11.2 |
Data import |
Allow data to be imported rapidly into the system, by mapping of data in xls to a form, so existing datasets can be imported to provide continuity with existing trends. |
| Functional requirements |
System management |
11 |
System management |
11.3 |
Task Management |
Provide users with administrative roles EWARS with a way of managing tasks that are assigned to them from users. Administrators at different geographic levels should only see tasks relevent to them. |
| Functional requirements |
System management |
11 |
System management |
11.4 |
Digest emails |
Provide option for users to receive digest emails once a day or once a week, containing a summary of key information. |
| Functional requirements |
System management |
11 |
System management |
11.5 |
Interoperability |
Support interoperability with other systems, by supporting an appropriate set of APIs to permit internal/external accessibility and sharing of data. |
| Functional requirements |
System management |
11 |
System management |
11.6 |
Data sharing |
Control how external users access data through approval requests for specific indicators or entire forms. Add further restrictions based on specific locations or timeframes. |
| Non-functional requirements |
Non functional |
11 |
System management |
11.7 |
Offline caching |
Support local caching or download of documents in a seamless way, for low bandwidth settings. |
| Functional requirements |
System management |
11 |
System management |
11.8 |
Community of practice |
Provide latest news items and best practice related to the EWARS in emergencies (for example new user guidance, blog posts, new features or functionality). |
| Functional requirements |
Mobile |
12 |
Mobile |
12.1 |
Usability |
Perform all the essentials for data collection and reporting, and alert management, on a mobile application. |
| Functional requirements |
Mobile |
12 |
Mobile |
12.2 |
Data connectivity |
The mobile application should provide the ability to submit reports via a data connection and, if none is available, then via submission of reports over SMS. |
| Functional requirements |
Mobile |
12 |
Mobile |
12.3 |
SMS Gateway |
The entire system should work as a desktop version, allowing it to operate completely offline and sync just to send/receive new data. This should also act as an SMS gateway, if a local version if needed for the mobile application. |
| Functional requirements |
Mobile |
12 |
Mobile |
12.4 |
Location |
If lat lon coordinates from a health facility or community based case are not available, the mobile app should sync back the coordinates to the main application. |
| Functional requirements |
Mobile |
12 |
Mobile |
12.5 |
Device management |
Any phone devices that are distributed with the mobile application should be registered in the system through tracking of IMEI and SIM card numbers in case they are lost or stolen. |
| Functional requirements |
Mobile |
12 |
Mobile |
12.6 |
SMS feedback |
Push SMS messages back to users at all levels, via the SMS gateway, should be permitted to provide automated feedback based on specific events and/or at specific time intervals. |
| Non-functional requirements |
System installation, maintenance and upgrading |
13 |
System installation |
13.1 |
Local installation |
Allow installation on local servers, with periodic synchronisation to a central server to receive software updates, if a Ministry of Health requires a full local installation. |
| Non-functional requirements |
System installation, maintenance and upgrading |
14 |
System maintenance |
14.2 |
System software dependencies |
The solution should have minimal system-level software dependencies in order to ease deployment and installation. |
| Non-functional requirements |
System installation, maintenance and upgrading |
15 |
System upgrading |
15.3 |
Upgrade workflow |
The solution should be easily upgradeable using a managed workflow for the central cloud-based installation. |
| Non-functional requirements |
System installation, maintenance and upgrading |
15 |
System upgrading |
15.4 |
Upgrade automation |
Any installations of the solution should check with the global system for upgraded components and database changes and apply them automatically. |
| Non-functional requirements |
System installation, maintenance and upgrading |
15 |
System upgrading |
15.5 |
Upgrade safety |
All updates and upgrades should be performed in an automated way and allow for rollback to previous versions in the event of failure or critical bugs. |
| Non-functional requirements |
System installation, maintenance and upgrading |
15 |
System upgrading |
15.6 |
Upgrade size |
To reduce downtime and risk of overall failure, individual components of the solution should make updates/upgrades through smaller scale updates versus larger overall updates to external and internal systems. |
| Non-functional requirements |
System installation, maintenance and upgrading |
15 |
System upgrading |
15.7 |
Upgrade versioning |
Individual components of the solution should be versioned and declare their version dependence on other system components to ensure feature mismatch is avoided. |
| Non-functional requirements |
System performance |
16 |
Performance and scalability |
16.1 |
Reliability and up-time |
The solution must maintain high availability as well as a high uptime rate throughout the year. |
| Non-functional requirements |
System performance |
16 |
Performance and scalability |
16.2 |
Minimal disruption |
The solution should be able to perform in-place upgrades/updates without any disruption to services, especially during periods of high usage. |
| Non-functional requirements |
System performance |
16 |
Performance and scalability |
16.3 |
Redundancies |
The solution needs to be highly available and redundant across multiple data centers in order to allow multiple redundancies in case of failures at the data center level. |
| Non-functional requirements |
System performance |
16 |
Performance and scalability |
16.4 |
Scalability |
Emergencies can happen anywhere and at anytime, and this can create sudden surges in demand on servers. The solution should be able to scale quickly and at a moments notice in order to meet and/or exceed resource requirements to support load within the system. |
| Non-functional requirements |
System performance |
16 |
Performance and scalability |
16.5 |
Auto-scaling |
The solution must be capable of auto-scaling to an extent in order to address changes in usage throughout weeks and minimize the cost of the system during low usage periods. |
| Non-functional requirements |
Data security |
17 |
Data security |
17.1 |
Data backups |
The solution should provide at a minimum 5 day rolling snapshots of application servers, 7 day rolling backups of database servers and monthly backups of file data. |
| Non-functional requirements |
Data security |
17 |
Data security |
17.2 |
Data encryption |
Encryption of data exchanged between client and server should be required for all content, with the exception of any explicitly marked for public content. |
| Non-functional requirements |
Data security |
17 |
Data security |
17.3 |
Security requirements |
Offline desktop versions should only work if they can ensure availability of technologies such as SSL and database encryption. |
| Non-functional requirements |
Device and browser compatibility |
18 |
Device compatibility |
18.1 |
Device compatiblity |
The mobile solution should be supported on Android and iOS and be publicly available through respective App stores. |
| Non-functional requirements |
Device and browser compatibility |
19 |
Browser compatibility |
19.2 |
Browser compatibility |
Web-based versions of the solution should fully support a range of common, modern browsers (e.g. Chrome, Firefox, IE, Safari) and provide the same functional features. |
| Non-functional requirements |
Help and support |
20 |
Help and support |
20.1 |
Online guidance |
The solution should provide online and offline guidance for users, to explain how the application works as a first level of support. |
| Non-functional requirements |
Help and support |
20 |
Help and support |
20.2 |
Inline guidance |
As a first level of support is needed, in-line guidance should also be provided in key areas within the solution. |
| Non-functional requirements |
Help and support |
20 |
Help and support |
20.3 |
Helpdesk |
Fully supported ticketing system, to log and manage support requests from frontline users. |