Roadmap

Version 2.7 - February 17. 2012

Launchpad overview

  • Translations of database content | Blueprint

    We need a solution for translations of database content. This means that it should be possible to translate and later view the most relevant database objects / content in any language. It should be possible for each user to decide what language she wants to the system to utilize. The system should have a base language and cater for any number of translations of the base language. The objects to enable translations for must include data elements, indicators, validation rules, groups and group sets.

    This will be useful in countries where e.g. English is not the official language and it is desired to be able to view the content in English, or where there are more than one official language spoken by different regions in the country.

  • Data locking | Blueprint

    We need functionality for locking data sets from further data entry. At a certain stage data is considered to be final and hence it should not be allowed to modify or enter additional data through the data entry interfaces including web and j2me mobile client.

    We need a solution where a data set has a given number of days before it is automatically locked. The number of days are relative to the end date of a period. For instance, a data set can be given 15 expiry days. If in July, it means that at June 15 the system should automatically lock the the data entry form for the month of May.

    We need a means for overriding this automatic locking for situations where exception must be given to certain org units / periods. It should be possible to define a lock exception for a combination of period, org unit and data set. This exception will then allow for additional data entry for the mentioned combination even if the data set is expired / automatically locked.

  • Option sets | Launchpad overview

    We need support for option sets. An option set should have a set of predefined options. These options will be used in tracking module data entry for pre-defined values for both program-based and anonymous events. In data entry the options in the option set should be rendered as a drop-down list, also with an auto-complete function. It should be possible to assign an option set to any number of data elements.

    For instance it should be possible to define an option set called "Delivery type" with options for "Normal delivery", "Breach delivery", "Caesarian section" and "Assisted delivery". This option set can then be assigned a data element called "Delivery type". Then in all types of data entry in data records module it should be displayed a drop-down list with all of the mentioned options.

  • Chart options in data visualizer | Blueprint

    Provision of various chart options in data visualizer module: i) Domain and range axis labels for displaying the units of measure of the chart ii) Target line for displaying the desired target value iii) Trend line for displaying the trend of the chart data iv) Hide legend and title to make more space for the chart itself v) Dynamic inclusion of the organisation unit of the currently logged in user on order to make charts more reusable.

Change log

Version 2.6 - December 27. 2011

Launchpad overview

  • Web API | Blueprint

    Web API for read-only access to reports and meta-data. This release will focus on read operations and a few write operations. The API will expose objects from the domain model which implements the IdentifiableObject interface. It will provide representations of the meta-data associated with these objects primarily in HTML, XML, JSON and JSONP formats. Certain objects like standard Report, Chart, ReportTable, Resource and MapView will expose additional data resources, where the aggregated data values (not the meta-data) is exposed. These resource will have representations in HTML, PNG and PDF formats. A limited set of write operations should be implemented for sending sets of data values and for posting message conversations and replies to messages. This Web API is intended to be used by external clients such as application running on mobile devices and CMS / Portal solutions running on external servers.

    The Web API should conform to the REST architectural principles as far as reasonable. This implies that i) Services exposed and manipulated as resources which are uniquely identified with URIs (URLs). ii) A uniform interface through HTTP where the HTTP method (verb) semantics are correctly implemented and the services return adequate response codes. iii) Linkable resources, meaning that clients will make state transitions (navigate) only through actions which are dynamically identified within the resource (in the form of hyperlinks). iv) A rich set of resource representations including formats such as HTML, XML, JSON, JSONP and PNG.

  • Data exchange: Stable object identifiers | Blueprint

    Stable object identifiers refer to identifiers for domain objects which do not change over time and are independent of database internal identifiers, naming conventions, manual modifications and the like. Maintaining stable identifiers has the potential of simplifying and making more robust the process of exchanging meta-data and data between systems.

    For the purpose of integration between DHIS 2 and external collaborating systems as well as different instances of DHIS 2, having stable object identifiers is a requirement for efficient meta-data and data exchange. DHIS 2 must add such a stable identifier to all objects in the code domain model. The identifiers should be universally unique in order to simply implementation and maintenance.

  • Data mart and reports: Organisation unit group set analysis | Blueprint

    DHIS 2 provides the ability to classify organisation units (such as by type, ownership) and build alternative organisation unit hierarchies (such as local government structures) through the concept of organisation unit groups and group sets. Currently the only way to utilize this in aggregate data analysis is through external tools such as Excel Pivot tables.

    First, DHIS 2 must provide a dedicated data mart with data aggregated on the organisation unit group set dimension, as well as the usual data element/indicator and time dimensions. This implies that aggregated values for all combinations of data elements/indicators, periods and organisation unit groups must be readily available for consumption by internal and external analysis tools.

    Second, the report table, chart and web pivot analysis tools in DHIS 2 must be able to utilize and provide analysis based on organisation unit group sets, in addition to the current analysis based on the organisation unit hierarchy.

Version 2.5 - October 15. 2011

Launchpad overview

  • Patient module: Single-event data management | Blueprint

    Support for single events will enable the patient module to manage data for use-cases such as “vital events” which involves arbitrary events such as births and deaths.

    The patient module should support capture and management of single events which might occur one or many times. Currently the patient module supports data captured from a predefined life-cycle represented through programs with program stages. This use-case implies that it should be able to capture data for single events outside any program or stage.

  • Mobile web interface: Data capture and basic analysis for low-end devices | Blueprint

    DHIS 2 needs an easy-to-use web-based interface for data capture and basic reports targeted at low-end mobile phones; first in order to utilize the expanding GPRS coverage in developing countries and avoid the pitfalls of installed client applications, second in order to utilize the large existence of low-end mobile phones and experience with Internet based services.

    DHIS 2 needs a new module for capture and basic analysis for low-end devices, primarily mobile phones with small screens. It should be possible to enter data for any number of data sets, periods. Organisation units may be confined to the users home organisation unit. The system should be able to send data in a single batch to the on-line server after the data entry form has been completed.

  • Data visualizer: Module for ad-hoc charting and reporting | Blueprint

    The current chart tool in DHIS 2 is based on the concept of defining a chart template which later is generated and populated with data based on certain input parameter.

    DHIS 2 needs a new module for producing dynamic ad-hoc analysis including charts and tabular reports. The system should provide selection of arbitrary indicators, data elements and periods. Organisation units should be selected through the boundary organisation unit - organisation unit level paradigm currently used in the GIS module. It should be possible to display charts as bar, line and pie after the input selection has been done. The aggregated data used in the chart should be displayed in a table.

    The Ext / Sencha javascript framework version 4 provides great support for both charts and interactive user-interfaces, and will be utilized for this module.

Version 2.4 - August 20. 2011

Launchpad overview

  • Patient module: Stabilize and improve performance of current functionality | Blueprint

    The patient module, also referred to as NBITS and beneficiary module, is a component within DHIS 2 which manages case-based data.

    The patient module has gone through several changes in the last year and there is a need for stabilizing the current functionality. The module needs thorough examination in terms of defining what is the desired system behaviour and potentially improving the current functionality to reach a stable and mature level. Also, all operations in the patient module must be examined and tested regarding performance and potentially improved in order to reach an acceptable level.

  • Data entry: Off-line capabilities for data capture | Blueprint

    Off-line data entry capabilities have the potential of being extremely useful in areas with limited and unstable network connectivity as one can continue to benefit from the advantages of centralized deployments.

    The data entry module needs functionality for capturing data while the client is off-line. Off-line implies that there is no network / Internet connectivity available. In this mode, data should be captured in a local storage, as opposed to being sent to the on-line server. The user must receive a notification regarding the off-line status and the number of data values which are currently being stored locally. This information must be updated in real-time. When the client gets back on-line the data should automatically be sent to the server. The user must receive feedback of the on-line status and a notification regarding the outcome of operation of synchronizing data with the on-line server.

    It is not required that the data entry module is displaying existing data values already stored on the on-line server in the data entry forms when in off-line mode. It is not required at this stage that the user can be off-line when logging in to the system.

    This function will utilize the local storage capabilities in web browsers defined by the Web Storage W3 specification, which is more or less supported by all major browsers since the release of Internet Explorer 8.

  • Data mart: Performance scaling on CPU cores | Blueprint

    DHIS 2 must deal with increasingly large amounts of data and there must be ways of scaling up the data mart processing capacity, especially regarding large scheduled data mart processes which must finish overnight.

    The data mart process needs to be scalable in terms of CPU processing power / number of CPU cores available. The data mart process must be split into multiple tasks which can be processed in parallel and utilize available CPU processing power (CPU cores). The number of CPU cores available should be configurable in order to best utilize any server environment.

  • GIS: Symbols for thematic map layer | Blueprint

    The GIS module should be able to display symbols mapped to classes for thematic mapping. This applies to both polygons and points. This will be similar to the way legends / colors are currently mapped to classes (data intervals), the difference being that data will be visualized by symbols rather than colors.

    The symbols mapped to classes should be configurable through custom “symbol sets” similar to the way legends / colors are configured currently. It should be possible to associate these “symbol sets” with specific data elements and indicators similar to the way legends / colors are associated currently.