DHIS 1.4
Overview
The District Health Information Software version 1.4 will still rely on MS Office to some extent for it's core program modules, but it is at the moment regarded as the last version to predominantly rely on Office/VBA. Version 1.4 will NOT support Office 97, only Office 2000/2002/2003 and later.
Version 1.4 should be regarded as a "bridging" version over to version 2, which will predominantly rely on Java (even if developments related to Mono does not exclude .NET modules or components in the future).
Installation instructions
Please read these instructions:
Installation instructions
New Features in DHIS 1.4
Main differences compared to version 1.3.0.x are:
- Ability to capture data linked to any level in the Organisational Hierarchy.
- Ability to capture "meta-data", or data about data (for instance, the date and time of submission, name of person collating the data at the facility level, whether the data validation has been run, etc).
- Flexible hierarchy supporting any number of levels from 2 upwards.
- More normalised internal structure (increased use of internal Identifiers), resulting in smaller database size.
- Support for any data collection frequency for routine data
- Support for daily capture of data like hospital midnight census etc.
- Support for user-defined data sets for more customised data entry
- User-defined grouping of data elements, indicators and organisational units
- Full integration of routine data, semi-permanent data, and survey/audit data through an improved indicator engine.
- XML-based integrated export/import of data and all resource tables (NOTE: Office 2000 does not support native XML, so a hybrid export/import solution will be developed for this version of Office).
- Ability to store data on most SQL-compliant DBMSs (at least Access, MySQL and/or PostgreSQL, SQL Server, and ORACLE).
- Ability to store and use TARGETS for any Organisational Unit.
- Ability to store and use BENCHMARK values for comparative purposes (in the case of for instance an indicator like "Infant Mortality", benchmark values would be Infant Mortality rates for a range of different countries, enabling users to choose one or more to compare their own indicator values with.
- Ability to extrapolate current trends forward into the future and automatically compare it with targets.
Downloads and Mailing list
Reports and analysis
How to use JasperReports to make standardised reports for DHIS 1.4
How to report bugs
This page provides a rather detailed explanation, with explanatory screenshots, on how to do proper bug reporting, and as well a quick guide for how to follow code and do changes in the DHIS 1.4 application. The same is sent to the dhis 1.4 mailing list, but here the expalanatory screenshots are provided as well. This is for all who are doing testing for, and development of, the DHIS 1.4 application. Please read!
DHIS 1.4 Bug reporting and fixing
Feedback
Feedback is of course most welcome and we recommend the DHIS 1.4 mailing list for communication. See DOC:Mailing lists for more information.
Import/Export concepts
CONCEPTUAL EXPORT/IMPORT FRAMEWORK
DHIS 1.4 is using a hybrid XML and comma-delimited text format, where the large core data tables (these can easily be hundreds of thousands of records) are exported directly to comma-delimited text files "as is". All the resource ("lookup") tables are on the other hand exported into one combined XML file. The text file(s) and XML file are subsequently compressed into one 7-zip file for transfer to the destionation. When importing, users will select the 7-zip file, it's content is extracted and inserted into a temporary Access database file - which is then compared with the existing database to differentiate between new data, updated data, etc.
The reason for choosing this hybrid solution instead of only using XML is that a large number of DHIS 1.4 users ares still using Access 2000, which does not have native support for XML export/import. We therefore ended up writing our own XML export/import class, but because that's inserting records sequentially, it's very slow when dealing with ( i.e. importing) large number of records.
The intention has always been to switch to XML fully when the big majority of users had switched to Access 2003/2007, but I don't know exactly when that will happen. We are also in the process of enabling DHIS 1.4 users to store data on other DBMSs (MySQL, PostgreSQL, SQL Server, etc), but I don't know what impact that will have on this issue. We have had some surprises with MySQL (e.g. inserting indexes in MySQL is ridiculously slow compared to e.g. Access), and since inserting comma-delimited data always is supported (and fast) we might need it longer than expected.
TECHNICAL FRAMEWORK
1. The core data tables (RoutineData, SemiPermanentData, SurveyAuditData, OrgUnitDataElementParameterData, etc) are simply "dumped out" exactly as they are in comma-delimited format - one .txt file for each table. See Form_ExportToXMLText object in DHIS_CORE.mdb for details
2. All the relevant resource tables are exported to one integrated XML file, see the "Private Function WriteSchema" in the XMLExport object in DHIS_CORE.mdb for details.
3. Note also that the configuration for this XML export is defined using the "Advanced Export (Components)" form under Export/Import in the DHIS Core module.
Conceptual issues around reports on semi-permanent data & phenomena
(This is cut form an e-mail from Calle Hedberg April 20, 2008)
Vincent Shaw in Zambia has just pointed out that the "Standard Reports" does
not work with Semi-permanent data (Standard reports have been designed to
deal with routine data, but that was obviously not made clear enough in the
interface):
"I was wanting a report on the semi-perm data (using fac database) and found
it does not work - standard reports/datafilesetup reports/ - it gives an
error message because there is no choice in the big blank box to select..."
We are looking at ways of enabling those same reports for Semi-permanent
data, but it might be helpful to explain some of the conceptual / technical
issues involved and seek views from others on how to extract/design reports
for such data. I will here concentrate on three aspects: (1) That a set of
semi-permanent data elements for a facility can be viewed as a "Facility
profile"; (2) the nature of the data period types used for such
semi-permanent data elements; (3) what implications it has for
"semi-permanent data" reports.
(1)
Let us say that we have defined and populated about 100 semi-permanent data
elements for our facilities, covering such phenomenas as numbers of staff
for different categories, types of services rendered, opening hours,
equipment, infrastructure, geography, access to the facility, catchment
population, etc etc. The combined total of those elements values for a
facility can then be construed as a "profile" of that facility. (Such data
is often only collected through facility surveys, but semi-permanent data
elements that get updated as soon as possible after a change has taken place
are better - then the "facility profile" will be more up-to-date).
One problem is of course that each of these let us say 100 semi-permanent
data elements can change at any time: For instance, on January 5th the
facility gets another nurse, on January 28th one lay consellor leaves, on
february 13th electricity is being installed, on march 7th the only blood
pressure machine breaks down, etc etc - changes to something is always
taking place in a real-world environment.
(2)
Two data period types - "OnChange" and "Survey" - are special in the sense
that they do not have regular data periods, but can have "random" ValidFrom
(start) and ValidTo (end) values. "OnChange" data periods have two
additional constraints: they must be subsequent in time, and individual
validity periods cannot overlap. So if you use OnChange for the
semi-permanent data element "Professional nurses in facility", then each
data value stored must have a validity period that ensures continuity with
no "unknown" gaps and no overlaps:
2005/01/01-2006/03/15: 2 prof nurses;
2006/03/16-2007/04/25: 1 prof nurse;
2007/04/26-2007/05/31: 0 prof nurse;
2007/06/01-2008/01/20: 1 prof nurse;
2008/01/21-9999/12/31: 2 prof nurses.
The following can NOT be allowed, because it would result in a period with
unknown nurses:
2005/01/01-2006/03/15: 2 prof nurses;
2006/03/16-2007/04/25: 1 prof nurse;
2007/06/01-2008/01/20: 1 prof nurse;
2008/01/21-9999/12/31: 2 prof nurses.
Ditto for the following, because it would result in two conflicting values
for the first 3 weeks of January 2008:
2005/01/01-2006/03/15: 2 prof nurses;
2006/03/16-2007/04/25: 1 prof nurse;
2007/04/26-2007/05/31: 0 prof nurse;
2007/06/01-2008/01/20: 1 prof nurse;
2008/01/01-9999/12/31: 2 prof nurses.
The "Survey" data period type can also have 'random' start and end validity
dates, but without any constraints related to period from e.g. different
surveys being stringed together without "gaps" etc. For surveys, it is
usually completely up to the persons doing/interpreting the survey how they
determine the validity period of each result. And note also that survey data
elements usually have only one value in any case - often the value
reflecting the situation as it was on the day/time of the survey visit.
(3)
Given the fact that many of our semi-permanent data elements have these
"random" validity periods - what can or will users expect in terms of
standard reports? (I'm here referring to "standard reports" as being reports
that contain the "raw" or "directly derived" data as it is stored in the
database, as opposed to more sophisticated reports with indicators or
advanced statistical analyses etc). We have at least three basic options,
and let us in this example continue to assume we have 100 semi-permanent
data elements:
(a)
With no overlapping data periods and no gaps, we can draw a report
REFLECTING THE SITUATION AS IT IS ON ONE SINGLE DAY. Such a report will then
show extract the relevant 100 values from the database, values that were
valid on the specific day.
(b)
We can draw a report for a larger validity period (e.g. Jan-March 2008), and
then just list all valid values within that period. So if data element no 63
CHANGED during the period the report will list all the values. Example, if
63 is "Piped water" and piped water was installed on march 03:
62: "Electricity - Grid", 2008/01/01-2008/03/31, Yes
63: "Piped water", 2008/01/01-2008/03/02, No
63: "Piped water", 2008/03/03-2008/03/31, Yes
Etc.
Such a report might contain 113 data values, because a number of data
elements changed values during the report period.
(c)
A more complicated variety would be one with exactly 100 values, one for
semi-permanent each data element, but where values that changed during the
report period are combined/aggregated to create one "representative" value.
The question is of course: How to you determine what is representative for
the report period? Use the value at the beginning or mid or end of the
report period? Turn all combinations of "Yes" and "No" into "Maybe"? Average
out values, so that 3 Blood pressure machines during the first month and 4
BPMs during month 2 and 3 become "3.66" BPMs?
It should be noted that in the South African "Quarterly Report" for
Strategic Planning, they usually opted for using the value representing the
situation at the END of the reporting period.
(4)
For now, we are enabling option (a) above as a standard report, because it
is non-ambigous - but we would like views from users about (b) and (c) as
well as report needs NOT covered by those...
