  0 Table of Contents |
 1 Home |
   1.1 Changes |
| 1.2 Dependencies |
| 1.3 References |
| 1.4 Adapting Guidelines for Country use |
 1.5 License |
| 2 Business Requirements |
| 2.1 Concepts |
| 2.2 Generic Personas |
| 2.3 User Scenarios |
| 2.4 Business Processes |
| 2.5 Data Dictionary |
| 2.6 Decision-support logic |
| 2.7 Scheduling logic |
| 2.8 Indicator and Performance Metrics |
| 2.9 System Requirements |
| 2.10 Functional Requirements |
| 2.11 Non-functional Requirements |
| 3 Data Models and Exchange |
| 3.1 System Actors |
| 3.2 Sequence Diagrams |
| 3.3 Transactions |
| 3.4 Indicators and Measures |
| 3.5 Codings |
| 4 Deployment |
| 4.1 Security and Privacy Considerations |
| 4.2 Testing |
| 4.3 Test Data |
| 4.4 Reference Implementations |
| 4.5 Trust Domains |
| 4.6 Downloads |
 5 Indices |
 5.1 Artifact Index |
| 5.1.1 A birth defects surveillance mobile application should be able to function as a standalone (for training purposes, small-scale surveillance or other uses) and/or contribute data to a centralized database, depending on local protocols |
| 5.1.2 Accept data from multiple input methods, including paper and geocoding (GPS) |
| 5.1.3 Access to data, data transfer and data storage are secured (encrypted) |
| 5.1.4 Adhere to complex password requirements |
| 5.1.5 Adjust display to fit small screens (e.g. on mobile phones) |
| 5.1.6 Alert user when navigating away from a form without saving |
| 5.1.7 Allow adaptability to multiple operating systems (e.g. Windows, Linux, IOS, Android) |
| 5.1.8 Allow admin user to request password reset |
| 5.1.9 Allow cascading user management and assignment of roles |
| 5.1.10 Allow for data exchange and efficient synchronization across multiple facilities and points of service when Internet is available, even when it is intermittent and slow |
| 5.1.11 Allow roles to be associated with specific geographical areas and/or health-care facilities |
| 5.1.12 Allow user to change their own password |
| 5.1.13 Allow user with permission to create a new user and temporary password |
| 5.1.14 Anonymize data exported from the system |
| 5.1.15 Architecture of the solution is consistent with architecture of HIS |
| 5.1.16 Automatically log out the user after specified time of inactivity |
| 5.1.17 Be able to accommodate at least [x number of]a concurrent users |
| 5.1.18 Be able to accommodate at least [x number of]a health-care facilities |
| 5.1.19 Be able to revert to the latest functional version of the solution without losing data (server backup/restore, disaster recovery plan) |
| 5.1.20 Be reliable and robust (minimize the number of system crashes) |
| 5.1.21 Be user-friendly for people with low computer literacy |
| 5.1.22 Communicate with external systems through mediators |
| 5.1.23 Compatible with range of mobile devices, including smartphones and tablets |
| 5.1.24 Configure business rules in line with guidelines and standard operating procedures |
| 5.1.25 Configure error messages |
| 5.1.26 Configure system centrally |
| 5.1.27 Configure workflows and business rules to accommodate differences between facilities |
| 5.1.28 Easy to learn and intuitive to enable user to navigate between pages |
| 5.1.29 Enable earlier versions of records to be recoverable |
| 5.1.30 Enable system deployment in environments subject to power loss |
| 5.1.31 Generate analysis of the usage of different system features and reports |
| 5.1.32 Generate IDs that are unique across different installations or sites |
| 5.1.33 Have ability to easily back up information |
| 5.1.34 If possible, the system should be embedded into the maternal/neonatal information system as an additional module |
| 5.1.35 Link with insurance systems to verify eligibility and submit claims |
| 5.1.36 Lock out user after a specified number of wrong password attempts |
| 5.1.37 Log access to data summaries, reports, analysis and visualization features |
| 5.1.38 Log access to views of individual client records |
| 5.1.39 Log all activities performed by the user, including date- and timestamp |
| 5.1.40 Log all data and system errors |
| 5.1.41 Log exchange of data with other systems |
| 5.1.42 Log system logins and logouts |
| 5.1.43 Must have ability to store images and other unstructured data |
| 5.1.44 No personally identifiable information could be shared from the local device in the country to a cloud server or other servers out of the country |
| 5.1.45 Notify user if their account is locked due to wrong password attempts |
| 5.1.46 Notify user of password change to their account |
| 5.1.47 Notify user to change password the first time they log in |
| 5.1.48 Notify user to regularly change their password |
| 5.1.49 Permit independent security audits to check security compliance on a regular basis, if required by protocol |
| 5.1.50 Prevent remembering username and password |
| 5.1.51 Provide a means to ensure confidentiality and privacy of personal health information |
| 5.1.52 Provide a unique version number for each revision |
| 5.1.53 Provide ability for allowed users to view confidential data |
| 5.1.54 Provide ability to create, read, update and delete report templates to use for automated reporting |
| 5.1.55 Provide access to data through APIs |
| 5.1.56 Provide capacity of the solution to be linked to data visualizer tool (e.g. Pw Bi, DHIS2) |
| 5.1.57 Provide capacity of the solution to extensive reporting and analytic capabilities (e.g. export CSV files/usage metrics/built-in reporting and analytics) |
| 5.1.58 Provide encrypted communication between components |
| 5.1.59 Provide guidance to users to better support clinical guidelines and best clinical practices |
| 5.1.60 Provide informative error messages and tool-tips |
| 5.1.61 Provide mechanism to securely change a user's password |
| 5.1.62 Provide password-protected access for authorized users |
| 5.1.63 Provide technical documentation of the IT solution (e.g. system architecture documentation, application programming interface (API) documentation) |
| 5.1.64 Provide user guidelines and training materials to effectively use the IT solution |
| 5.1.65 Record all authentication violations |
| 5.1.66 Report version number when saving data to the database |
| 5.1.67 Require each user to authenticate by role before gaining access to the system |
| 5.1.68 Reset user's password in a secure manner |
| 5.1.69 Scalable to accommodate new demands |
| 5.1.70 Show the number of records that are not yet synchronized |
| 5.1.71 Simplify data recording through predefined dropdown menu or searchable lists, radio buttons or checkboxes |
| 5.1.72 Solution should use international coding standards for data whenever possible
Countries can develop their own local coding system, but WHO recommends use of ICD-10 coding system to classify congenital anomalies for international reporting and comparisons |
| 5.1.73 Store important system documents and information such as protocols, case inclusion criteria, surveillance population and similar important facets of the system, and make them available for retrieval as needed |
| 5.1.74 Support definitions of unlimited roles and assigned levels of access, viewing, entry, editing and auditing |
| 5.1.75 Support multiple languages |
| 5.1.76 Support real-time data-entry validation and feedback to prevent data-entry errors from being recorded |
| 5.1.77 The birth defects surveillance system to automatically make the reports I submit available in the system's data portal, if one exists |
| 5.1.78 The birth defects surveillance system to automatically send the reports I submit, by email, to a preconfigured distribution list |
| 5.1.79 The birth defects surveillance system to notify the birth defects specialist that a case needs to be reviewed using an application notification, email, SMS or other method |
| 5.1.80 The birth defects surveillance system to notify the surveillance data manager that the case has been updated with the missing information, using an application notification, email, SMS or other method |
| 5.1.81 The birth defects surveillance system to notify the surveillance programme manager when a report is marked as ready for their review, using an application notification, email, SMS or other method |
| 5.1.82 The search to match on partial information (e.g. partial birth dates) |
| 5.1.83 The system should be able to integrate with other approved systems, such as electronic medical records and public health databases, to allow for seamless data sharing and analysis |
| 5.1.84 The system to allow search parameters configuration (e.g. mandatory fields, when partial information is acceptable) |
| 5.1.85 The system to automatically calculate indicators based on preset rules |
| 5.1.86 The system to delete images and videos automatically from the device, once uploaded into the birth defects surveillance system, if required by local protocols |
| 5.1.87 The system to display sufficient data to identify the case |
| 5.1.88 The system to require me (a user) to search to see whether the case record is already in the system before starting a new entry |
| 5.1.89 The system to retain history of updated information on the case record (e.g. observation notes) |
| 5.1.90 The system to return all potential matches based on search criteria |
| 5.1.91 The system to support me with visually identifying a birth defect by providing information about possible defects and syndromes (including photos, descriptions and ICD codes based on the WHO QRH) when I indicate on the screen an anatomical region of the newborn |
| 5.1.92 The system to support with the necessary information related to case inclusion criteria, if it is stored in the system
|
| 5.1.93 To approve the generated report using a digital signature or other method appropriate for the local context |
| 5.1.94 To be able to attach an identifier (e.g. QR code, barcode, fingerprint, photo) to the newborn's or mother's record based on national standards consent |
| 5.1.95 To be able to collect digital signatures from clients, if acceptable according to the local protocols |
| 5.1.96 To be able to configure report parameters when generating reports such as time range, geography and other details |
| 5.1.97 To be able to flag issues with a case and send that case to the data collector |
| 5.1.98 To be able to flag issues with a case and send that case to the surveillance data manager for review and follow up |
| 5.1.99 to be able to retrieve client information (e.g. newborn, mother, father) from existing electronic medical records and link it to the case record |
| 5.1.100 To be able to send the final determination regarding the diagnosis back to the care provider using an application notification, email, SMS or other method, if required by the local protocol |
| 5.1.101 To be able to update demographic information of newborn/mother/informant |
| 5.1.102 To bypass the standard flow as needed and jump between sections, except when local protocols demand consent to proceed |
| 5.1.103 To create a new case record with a unique ID and timestamp of record creation |
| 5.1.104 To have the ability to aggregate the data by time period and surveillance population |
| 5.1.105 To have the ability to deidentify the data and prepare the database for analysis and reporting |
| 5.1.106 To have the ability to make changes to the data (case records) |
| 5.1.107 To have the ability to query the data to look for issues of data quality |
| 5.1.108 To have the ability to see a summary of all birth defects cases captured in the health facilities participating in the surveillance system |
| 5.1.109 To have the ability to upload images and videos of the birth defect in the birth defects surveillance application or system |
| 5.1.110 To have the possibility to download the data to my own programme data centre |
| 5.1.111 To have the possibility to see or visualize medical data and previous measurements (log history) |
| 5.1.112 To produce reports based on stored templates |
| 5.1.113 To search with wildcards (using a symbol to replace one or more characters) |
| 5.1.114 To view a range of standardized visualizations (e.g. charts, tables, maps) |
| 5.1.115 Use industry standard user interface practices and apply them consistently throughout the system |
| 5.1.116 Warn user if no valid backup for more than a predefined number of days |
| 5.1.117 Work in environments subject to loss of connectivity |
| 5.1.118 Functional Requirement Categories |
| 5.1.119 Functional Requirement Categories |
| 5.1.120 LM.BDS.NFXNREQ.1 |
| 5.1.121 LM.BDS.NFXNREQ.10 |
| 5.1.122 LM.BDS.NFXNREQ.11 |
| 5.1.123 LM.BDS.NFXNREQ.12 |
| 5.1.124 LM.BDS.NFXNREQ.13 |
| 5.1.125 LM.BDS.NFXNREQ.14 |
| 5.1.126 LM.BDS.NFXNREQ.15 |
| 5.1.127 LM.BDS.NFXNREQ.16 |
| 5.1.128 LM.BDS.NFXNREQ.17 |
| 5.1.129 LM.BDS.NFXNREQ.18 |
| 5.1.130 LM.BDS.NFXNREQ.19 |
| 5.1.131 LM.BDS.NFXNREQ.2 |
| 5.1.132 LM.BDS.NFXNREQ.20 |
| 5.1.133 LM.BDS.NFXNREQ.21 |
| 5.1.134 LM.BDS.NFXNREQ.22 |
| 5.1.135 LM.BDS.NFXNREQ.23 |
| 5.1.136 LM.BDS.NFXNREQ.24 |
| 5.1.137 LM.BDS.NFXNREQ.25 |
| 5.1.138 LM.BDS.NFXNREQ.26 |
| 5.1.139 LM.BDS.NFXNREQ.27 |
| 5.1.140 LM.BDS.NFXNREQ.28 |
| 5.1.141 LM.BDS.NFXNREQ.29 |
| 5.1.142 LM.BDS.NFXNREQ.3 |
| 5.1.143 LM.BDS.NFXNREQ.30 |
| 5.1.144 LM.BDS.NFXNREQ.31 |
| 5.1.145 LM.BDS.NFXNREQ.32 |
| 5.1.146 LM.BDS.NFXNREQ.33 |
| 5.1.147 LM.BDS.NFXNREQ.34 |
| 5.1.148 LM.BDS.NFXNREQ.35 |
| 5.1.149 LM.BDS.NFXNREQ.36 |
| 5.1.150 LM.BDS.NFXNREQ.37 |
| 5.1.151 LM.BDS.NFXNREQ.38 |
| 5.1.152 LM.BDS.NFXNREQ.39 |
| 5.1.153 LM.BDS.NFXNREQ.4 |
| 5.1.154 LM.BDS.NFXNREQ.40 |
| 5.1.155 LM.BDS.NFXNREQ.41 |
| 5.1.156 LM.BDS.NFXNREQ.42 |
| 5.1.157 LM.BDS.NFXNREQ.43 |
| 5.1.158 LM.BDS.NFXNREQ.44 |
| 5.1.159 LM.BDS.NFXNREQ.45 |
| 5.1.160 LM.BDS.NFXNREQ.46 |
| 5.1.161 LM.BDS.NFXNREQ.47 |
| 5.1.162 LM.BDS.NFXNREQ.48 |
| 5.1.163 LM.BDS.NFXNREQ.49 |
| 5.1.164 LM.BDS.NFXNREQ.5 |
| 5.1.165 LM.BDS.NFXNREQ.50 |
| 5.1.166 LM.BDS.NFXNREQ.51 |
| 5.1.167 LM.BDS.NFXNREQ.52 |
| 5.1.168 LM.BDS.NFXNREQ.53 |
| 5.1.169 LM.BDS.NFXNREQ.54 |
| 5.1.170 LM.BDS.NFXNREQ.55 |
| 5.1.171 LM.BDS.NFXNREQ.56 |
| 5.1.172 LM.BDS.NFXNREQ.57 |
| 5.1.173 LM.BDS.NFXNREQ.58 |
| 5.1.174 LM.BDS.NFXNREQ.59 |
| 5.1.175 LM.BDS.NFXNREQ.6 |
| 5.1.176 LM.BDS.NFXNREQ.60 |
| 5.1.177 LM.BDS.NFXNREQ.61 |
| 5.1.178 LM.BDS.NFXNREQ.62 |
| 5.1.179 LM.BDS.NFXNREQ.63 |
| 5.1.180 LM.BDS.NFXNREQ.64 |
| 5.1.181 LM.BDS.NFXNREQ.65 |
| 5.1.182 LM.BDS.NFXNREQ.66 |
| 5.1.183 LM.BDS.NFXNREQ.67 |
| 5.1.184 LM.BDS.NFXNREQ.68 |
| 5.1.185 LM.BDS.NFXNREQ.69 |
| 5.1.186 LM.BDS.NFXNREQ.7 |
| 5.1.187 LM.BDS.NFXNREQ.70 |
| 5.1.188 LM.BDS.NFXNREQ.71 |
| 5.1.189 LM.BDS.NFXNREQ.72 |
| 5.1.190 LM.BDS.NFXNREQ.73 |
| 5.1.191 LM.BDS.NFXNREQ.74 |
| 5.1.192 LM.BDS.NFXNREQ.75 |
| 5.1.193 LM.BDS.NFXNREQ.76 |
| 5.1.194 LM.BDS.NFXNREQ.77 |
| 5.1.195 LM.BDS.NFXNREQ.78 |
| 5.1.196 LM.BDS.NFXNREQ.79 |
| 5.1.197 LM.BDS.NFXNREQ.8 |
| 5.1.198 LM.BDS.NFXNREQ.80 |
| 5.1.199 LM.BDS.NFXNREQ.9 |
| 5.2 Mappings |