dhis2-devs team mailing list archive

[Ola Hodne Titlestad <olati@xxxxxxxxxx>]

Hi,

As mentioned before the planned CBHIS needs to support a variety of use
cases around the HISP network. We have received requirements from India,
build into Abyot's design document, and earlier today also from Vietnam.

Another important use case is to support case-based data collection e.g.
related to vital events (births, deaths) and notifiable diseases which in
the DHIS 1.4 software stack is covered by the DHIS 1.4 Patient Module.

I've added a blueprint explaining about this kind of data before (
https://blueprints.launchpad.net/dhis2/+spec/case-based-data-module), but
would like to provide more detailed requirements related to how it is used
for Maternal Death Auditing in Zanzibar, a very important DHIS use case that
we will be needed also in many other countries and need to be supported also
in the DHIS2 stack. Use cases for monitoring notifiable diseases which is
also very much demanded around the HISP network will have a very similar
approach and needs as they are also catured by the functionality of the DHIS
1.4 Patient module which I cover here.

The Zanzibar case of Maternal Death Audit will then be one of the test cases
for the prototype of the new CBHIS in addition to India and Vietnam. But
first we need to see whether we really can find a smallest common
denominator among these three use cases and whether they all actually fit
within the desired scope of this development (or pherhaps need to be split
into separate modules/systems). That should be one of the points on the
agenda for tomorrow's conference call.

Anyway, based on how DHIS 1.4 supports the Maternal Death Auditing in
Zanzibar I've written up the requirements. Some of these are of course very
1.4 specific and need to be tranformed into DHIS2 terminology/platform, but
most of these requirements _can_ be applied directly in DHIS 2 due to the
similarities in the data model.

(The following text is also available in the attached pdf.)

*Rationale and summary of the use case:
*Every clinic or ward providing delivery services reports a monthly summary
form (aggregated data) for deliveries where maternal deaths is one of the
data elements.
This form is captured using the DHIS in the "normal" way for aggregated
(non-patient) data.
In order to reduce maternal mortality rate the MoH wanted more details on
the causes and related events of maternal deaths, e.g. the complications
leading to the death, action taken to avoid the death, and various details
about the deceived such as ANC history, social and educational status, home
village etc. To capture this information about every single maternal death
(institutional) the delivery facilities have to fill a special audit form
for every maternal death in their facility. This audit form is a case-based
form with the details described above as well as the name of the deceived
mother, the facility where the death occurred, and the date of death.

*Data elements and datasets
*This form is filled on paper at each facility and sent to the higher levels
where it is registered electronically into the DHIS patient module using a
custom form that looks exactly like the paper form.
In this patient module all the data items captured in the audit form are
represented as data elements, and they make up a dataset that represents all
the data captured in the form. In the user interface these data elements are
called Patient Data Elements, but under the hood they are just normal data
elements using the same table structure as other data elements. These data
elements are often of the type text, but can be of any of the following
types;
text, long text, yes/no, number, date, OLE object
In order to do analysis (meaningful aggregation) on the text-based data
values most of the data elements have pre-defined value lists that appear as
drop down lists in data entry where the user must select one of the
pre-defined values. These pre-defined values are defined in data set
management and each data element+ dataset combination has its own list or no
list at all (free data entry). It is also possible to have value lists that
are only meant as optional values, meaning that free text is allowed for the
same data element although a value list exists.
*Note that the value list functionality already exists in DHIS 2, as it was
recently implemented by Murod.
*
*Data values
*Each data value captured in the form is stored with a reference to the
patient, the orgunit, the date and the dataset. The values are of different
types defined by their data element types.

*Routine (aggregated) data elements
*In order to use these data efficiently for analysis it is possible to
define aggregated/routine data elements that are cohorts from the patient
data. These aggregated data elements are defined as expressions or formulas
describing how they are counted/aggregated from the patient data. E.g. in
the maternal death audit the user fills in the data element called "Direct
cause of the maternal death" with one of multiple pre-defined values (where
one is "Eclampsia").
If we want to know how many maternal deaths that was directly caused by
eclampsia we could define a new Routine Data Element called "Maternal deaths
with direct cause eclampsia" with an expression (criteria) like:
"Patient data element: "Direct cause of death" = "Eclampsia".". Expressions
can also be combinations of many patient data elements with criteria for
their values.
In the user interface these aggregated data elements are called Routine Data
Elements, and in addition to the normal properties of a data element they
also contain an expression for aggregation.
Every month, after all maternal deaths for the previous months have been
registered the user can generate the aggregated values for the Routine Data
Elements for the previous month.
That process looks up all defined Routine Data Elements and follows their
expressions to count how many "hits" they had for each organisation unit for
the selected month. Other period intervals are also possible, like quarterly
or annual. The result is a set of routine data values with references to a
routine data element, an orgunit and a period. These data values are then
exported to an xml file and later imported into the core DHIS module for
aggregated data.
Note that in DHIS 1.4 there are two separate backend databases for
aggregated and patient data. The two types of data values are slightly
different as patient data references patients and datasets in addition to
data element, period, and orgunit. With an online system the security of
patient data will of course be another important difference between
aggregated and patient data.

*Reports
*There are different types of reports involved here.
1)One is to simply print out the data entry form without any aggregation,
similar to data set report in DHIS 2. Standard and custom forms are
supported.
2) Another is to create a so-called cross tab report where you get a tabular
view to the data captured with all patient data elements as columns and each
case/patient per row.
3) Aggregated reports. Based on the defined routine data elements, data is
aggregated for specified routine data elements, periods and datasets, and
then displayed in pivot tables or other custom reports based on routine data
elements.

*Search records
*Per dataset it is possible to use one or more data elements and their
pre-defined values to search (query) the patient records. Results (with only
selected or all data elements) will be listed in a cross-tabbed report.

*Import/Export
*Just like with a normal DHIS system data is transferred between instances
using XML based import/export files. Metadata import/export is also
supported. What is new here is the option to export the generated Routine
Data to a standard DHIS 1.4 XML format for aggregated data that can be used
to import into the core module.


best regards,
Ola Hodne Titlestad
HISP
University of Oslo

Attachment: Case_based_auditing_and_surveillance_using_DHIS.pdf
Description: Adobe PDF document