System Admin Guide - LogicalOutcomes/DHIS2-FAQ GitHub Wiki

This brief guide will provide an overview of appropriate practices to guide the management of the DHIS2 implementation. This includes data management standards and practices, data security, and user management.

  • Abbreviations

  • Metadata standards and naming

  • Data Quality

  • System Features to promote data utilization

  • Hosting and technical set up

  • Data storage and safeguarding

  • Data Security Management

 

In the fall of 2016 LogicalOutcomes conducted interviews and document review, specifically:

  • Dr. Gillian Kerr (president of LogicalOutcomes) in regard to metadata standards

  • Steven Uggowitzer (senior architect at eSHIFT partner network), in regards to data management, system administration and security

  • Prosper Behumbiize (lead consultant with HISPUganda), in regards to data management practices

  • DHIS2 user and implementation guides, and materials from University of Oslo Academies

Abbreviations

API Application programming interface
DHIS2 District Health Information System
GIS Geographical Information System
LDAP Lightweight Directory Access Protocol
SA System Administrator
SU System User

Metadata standards and naming

To build a DHIS2 database, one thoughtfully transitions data collection forms and reports into a number of 'configuration files' that meet the 'meta-data standards' required by DHIS2. See the Templates tab for more on metadata requirements.

At present there is required method to manage metadata, although the DHIS2 community has preferred naming conventions. The principle here is to be consistent. For example, should you choose to use hyphens instead of spaces, consistently use the hyphen (-) or the underscore (_).

The configuration workbook follows data standards, structure, and requirements for character length by employing Camelcase (a typographical convention in which an initial capital is used for the first letter of a word forming the second element of a closed compound, e.g. PayPal, iPhone, MasterCard).

When preparing configuration spreadsheets, it is recommended to use Camelcase for translations specific to class names, language abbreviation, property, etc. Within the DHIS2 community, there are not a lot of emerging standards around data elements - different groups employ different standards. Most standards regarding metadata are around indicators.

Data Quality

To ensure quality in terms of accuracy, integrity and completeness of the data, DHIS2 can incorporate a number of features including:

  1. Use of data validation by data element

    a. See FAQ section on Data Quality: Validation rules and min/max limits

  2. Data sets can be open for a defined time period, then locked to restrict data entry

    a. This is set up through the Data Set app, click to Edit a dataset, set 'Expiry days'

  3. Managers can review 'complete' and 'incomplete' datasets, through Reports > 'Data Set' report

  1. Standardized reports for verifying the usage of data.  DHIS2 has basic audits on what the user does when logged to the system like how many users are logging into the system, how many data values have been entered etc..

    a. See the Reports app > Reporting Rate Summary, or Data Approval

System Features to promote data utilization

DHIS2 has a number of features to promote data utilization for users at all levels (i.e. country level, regional level, etc.).

To ensure a healthy up to date system that engages users, the following can be implemented:

  • End-user training

    • Give end users hands-on practice in a 'sandbox' space. Provide video and print out instructions. Provide refresher trainings every 6-12 months as required, especially when the DHIS2 is updated to a newer version. Ensure that end users are only given access to the Org Unit they require, and the data collection forms they need to use

  • Active use of messaging

    • Some instances benefit from using SMS, and/or the built in Message features of DHIS2. This moves communication off of email, and ensures people are getting up to date notices in a timely manner.

  • Permitted users have access to the system with username and password

    • See 'Users' section for more on how to set up users. Sometimes, if the end-user group is very large, it can be helpful to set up a 'self-registered user.' Refer to the DHIS2 User Manual, 'Settings' section on the 'self-registered user role' https://docs.dhis2.org/

    • Define user roles carefully, only giving access to the features required and no more

  • Ensures dashboards are ready for use, meaning, once you're ready to launch, the reports are visible for all to see.

  • For organizations that use Microsoft, DHIS2 allows for LDAP integration that can use passwords and user names from active directory connected with Microsoft. This gets a bit technical, try reading the instructions in the user manual https://docs.dhis2.org/2.22/en/implementer/html/ch08s05.html, or message the JIRA user board.

Hosting and technical set up

Due to the complexity of programs required to run DHIS2, and the programming codes based on Linux Ubuntu languages (not Windows), most organizations do not have the capacity for internal hosting.

Internal hosting is not advised.

In many cases, a client will maintain one or more instance of DHIS2:

(i) Development (sandbox)

(ii) Training

(iii) Production

Service offering agreement will allow for the client organization to be confident in case of the system failure. It will also be cheaper in the long run. System location and users’ locations are a consideration for stability – there are still many places where for example Amazon isn’t accessible. A review of user habits/locations etc. ensures the applicability.

For security, each DHIS2 instance is encrypted with an SSL certification in order to prevent hacking. This is another reason to outsource hosting: regular maintenance of the system (patches and addressing of bugs and hacks) is part of the host company responsibility.

Data storage and safeguarding

As most of the organizations may have their own policies regarding the handling, back up and retention, consultation should be carried out before intervention (i.e. offsite backups may not be part of company policy).

In most cases the hosting company will oversee these activities. Know who to contact, to understand the current processes in place. The client organization has to be clear about where the backups are being stored and will have access readily to back up files all the time. The client may also wish to hire a DHIS2 consultant to provide these smaller amounts of technical support (unless the server company is well adept in DHIS2).

The Dropbox method: day to day

  • Data remains within the DHIS2 cloud hosted instance for as long as the project requires.

  • The hosting company has the option to create backups and historic records. If desired, all the data and metadata can be stored and saved into a client owned Dropbox. Dropbox can also be encrypted. Providing appropriate permissions to the Dropbox users is imperative (i.e. is there a back up copy? Do 2-3 System Administrators have access?)

  • User passwords could be managing in encrypted Dropbox folders (i.e. on a document within the folder, accessible only by the System Administrator).

Longer term

  • The hosting company could also automatically store all the data into the Dropbox archives after a certain time period (i.e. 6 months), removing from the cloud hosting server.

  • DHIS2 has number of options for backups which are as follows:

    • The system can send backups to two different servers (in two different places).

    • Backups can be scheduled depending on client’s need (daily, weekly, monthly etc.)

    • Experiences users can use scripts to get backups automatically.

    • Backups can also be stored in ‘custom’ binary format which can be helpful for restoring to database of exact same version.

Restoring the database

  • Should functions become 'glitchy' or errors frequent, the client may wish to restore the database. This means, using a back up of the database and files, to erase and replace. This is a technical task, and requires use of a programming script to replace the system, and some testing to make sure it's working properly.

  • When restoring the database, ensure this happens at a time when no users are using the system (i.e. off time, or send a notice to all users re: not able to use for a 1-2 day period).

Data Security Management

Data security management ensures the proper access, erasure, security, and privacy.

  • Delete permissions should only be given to users who require this authority (i.e. System Administrator, or Manager). In case of accidental deletion, back-ups will be available.

  • The System Administrator(s) are responsible for controlling the access of all users and defining the rules for User Roles.

    • Only the SA should have access to view and change the User app in DHIS2.

    • Users should only have View access to the data they require

    • Once users are no longer required to access the system, their user accounts become de-activated by the system administrator.

  • Poor passwords are always a concern.

Password strength is a measure of the effectiveness of a password in resisting guessing and brute-force attacks. In its usual form, it estimates how many trials an attacker who does not have direct access to the password would need, on average, to guess it correctly. The strength of a password is a function of length, complexity, and unpredictability.

Passwords should be:

  • At least 10 characters

  • Use upper and lower case and numerals, without sequences like “ab”

  • Include special characters

LogicalOutcomes encourages the use of Password Meter for testing password strength. When testing strength, contractors should ensure that all passwords used for LogicalOutcomes rate at least “Sufficient” in the Password Meter. Everyone working with LogicalOutcomes should test their passwords for related work using the Password Meter. Contractors must not use the same password for non-LogicalOutcomes work.

Two mandatory rules for LogicalOutcomes passwords are:

  • Never use the “remember me” option to save your passwords on your computer (see LastPass for secure storage of passwords)

  • Use a different password for different applications

From <http://logicaloutcomes.net/data-security/>