Coding layout - Community-Based Health Information System (CBHIS)

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 datasetsThis 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 valuesEach 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 elementsIn 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.

ReportsThere 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.

  1. 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.
  2. 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 recordsPer 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/ExportJust 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

Case_based_auditing_and_surveillance_using_DHIS.pdf (60.8 KB)

Hi,

Abyot, Lars, Jørn and I have had some discussions in Oslo concerning the design of the CBHIS that I thought I would share with you before tomorrow’s call. These are my interpretations and views on what has been discussed and do not necessarily reflect what Abyot, Jørn and Lars thinks… Hope this will help to make tomorrow’s call more constructive.

**Summary of functional requirements:**I’ll do my best to provide a short summary of the three use cases we have seen so far from India, Vietnam and Zanzibar: Please fill in and correct me if needed.

India: The type of data captured very similar to routine data in the sense that it is basic health program data like “BCG vaccine given”, “DPT1 vaccine given” etc. BUT differs with regards to the owner of the data which are individual clients and households. In that sense the data elements are the same, but the “orgunits” are extended down to the lowest possible level, the individual. In addition there are requirements for a work planner system that helps to organise the out reach work of the health workers providing schedules and work plans on where to do household visits based on the data available (which chidren in the village are scheduled for DPT3 vaccine next week etc.).

There is a clear link to aggregated data as data elements can be derived directly from the household data (can even be the same data element), but aggregation is needed in order to analyse higher levels in the orgunit tree.

Zanzibar / DHIS 1.4 patient:
In this use case the data elements are also different from the routine as they are typically much more detailes than routine data, in a way zooming in on each case with more details. The orgunits are the same, but data is also belonging to individuals, although more as a reference for later lookup, not to keep track of patients/clients over time.

In this use case is is the details of each reported case that are important, not the name of the patient. Routine data are generated based on expressions and criteria to filter and count the detailed patient-level data.

Vietnam:
I have not fully grasped all the requirements here, but at first glance they seem quite similar to the Indian needs. The idea is for health programs to follow up individual clients (mothers and children) and register essential data on vaccination, ANC check-ups, deliveries. I know that e.g. in the big city of HCMC they want to have a central register with all pregnant mothers and I assume the same for newborn children, so in that sense it is a bit different from India where the focus is on the communities. That means that the link to household and village might not be as important, but the mother-child link is probably important, and the data also belongs to the reporting health facility (ward). So clients and health facilities own the data, similar to the Zanzibar case. But here the tracking of clients over time is important, as it is in India. Also here there is a clear need to produce aggregated reports based on the patient-level data, and from the forms provided by Tran the data elements for patient-level and routine seem very similar, and again like in India the main difference with the data is the owner, so I assume a lot of routine data and patient data can share the same data element name.

**Design choices:**Building on Abyot’s design, discussions we’ve had in Oslo and also the summary above my feeling is that we can reuse existing design concepts like data element, data set, and data entry form. We should probably differentiate in the GUI between Patient Data Elements and Routine (aggregated) Data Elements, but the same object seems to capture what we need. Similarly all registers/forms seem possible to represent as data sets and then if needed a custom data entry form can be designed on top of that. This seems very similar to what we already have in DHIS2. The expressions for how to generate aggregated data from patient data could fit into the concept of calculated data elements, at least if we extend it a bit.

If we go for this approach and reuse data elements and sets then we need to extend the dataset management functionality in order to specify what kind of data that is captured with the dataset since data entry will be quite different for patient and routine data and since we possibly need to use two different data value objects for patient and routine. We could e.g. do like 1.4 and add a “data table” property to datasets where we can specify whether it is patient or aggregated data (don’t like to use routine as it doesn’t capture semi-permanent data).

Then when you open data entry and select a dataset the screen and procedures will vary depending on what type of data that is going to be captured.

This means that we do not really need a new web module for meta data management and data entry for patient data, but in stead can extend the existing data dictionary and data entry modules. For the CBHIS work planner functionality I assume we need a new web module. Not sure how smooth it will work, but it could be an idea to have a global setting where the user can enable/disable patient data, meaning that a system without patient data enables would like pretty much like DHIS 2 today (using “Data Elements” in stead of the two types which can be annoying to the users that are not using this functionality).

Some complications from extending the use of the data element object would be to filter out patient data in datamart, report tables and all places where you only want to deal with normal aggregated data. I am not the one to answer whether that will slow down the mentioned functionality or not, but I guess that is something we need to look into.

Another complication I see from this would be the use of the same data element for both patient-data and aggregated data. As explained above, the meaning of the data is the same, it is simply the owner that is different (further down the hierarchy), so it seems natural to allow this kind of reuse. But how to we e.g. control that the aggregated data element is not registered also in routine data collection for the same orgunits that are also generating the same data from patient records? Maybe a new data element property that defines whether it is generated or registered directly? Obviously we need to do some thinking about this, but I think the general idea is that it would be very good to be able to seamlessly zoom in and out on data elements between aggregated and patient “orgunit” levels. That is something which is really requested by various stakeholders in global health.

TechnologiesI agree with Lars that we should keep this process as simple and fast as possible and therefore start by building on what we already have. My scenario of reuse above also supports this.
Still I also agree with Bob that this is a chance to think new and look at alternatives, but I think we should to it in gradual manner so that we do not slow down the (functionality) development process. Struts 2 and Spring Security seems like a good start to me. If we create a new branch in launchpad for CBHIS from today’s/next week’s or whatever trunk and start coding on the new CBHIS functionality there we could safely start such a process. I assume successful transitions to Struts2 etc could then be merged into trunk along the way (somehow). Or?

best regards,
Ola Hodne Titlestad
HISP
University of Oslo

···

On Wed, May 27, 2009 at 3:10 PM, Ola Hodne Titlestad olati@ifi.uio.no wrote:

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 datasetsThis 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 valuesEach 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 elementsIn 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.

ReportsThere 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.

  1. 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.
  2. 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 recordsPer 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/ExportJust 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

Hi

Hi,

Abyot, Lars, Jørn and I have had some discussions in Oslo concerning the
design of the CBHIS that I thought I would share with you before tomorrow's
call. These are my interpretations and views on what has been discussed and
do not necessarily reflect what Abyot, Jørn and Lars thinks... Hope this
will help to make tomorrow's call more constructive.

Summary of functional requirements:
I'll do my best to provide a short summary of the three use cases we have
seen so far from India, Vietnam and Zanzibar: Please fill in and correct me
if needed.

India: The type of data captured very similar to routine data in the sense
that it is basic health program data like "BCG vaccine given", "DPT1 vaccine
given" etc. BUT differs with regards to the owner of the data which are
individual clients and households. In that sense the data elements are the
same, but the "orgunits" are extended down to the lowest possible level, the
individual. In addition there are requirements for a work planner system
that helps to organise the out reach work of the health workers providing
schedules and work plans on where to do household visits based on the data
available (which chidren in the village are scheduled for DPT3 vaccine next
week etc.).
There is a clear link to aggregated data as data elements can be derived
directly from the household data (can even be the same data element), but
aggregation is needed in order to analyse higher levels in the orgunit tree.

Zanzibar / DHIS 1.4 patient:
In this use case the data elements are also different from the routine as
they are typically much more detailes than routine data, in a way zooming in
on each case with more details. The orgunits are the same, but data is also
belonging to individuals, although more as a reference for later lookup, not
to keep track of patients/clients over time.
In this use case is is the details of each reported case that are important,
not the name of the patient. Routine data are generated based on expressions
and criteria to filter and count the detailed patient-level data.

Vietnam:
I have not fully grasped all the requirements here, but at first glance they
seem quite similar to the Indian needs. The idea is for health programs to
follow up individual clients (mothers and children) and register essential
data on vaccination, ANC check-ups, deliveries. I know that e.g. in the big
city of HCMC they want to have a central register with all pregnant mothers
and I assume the same for newborn children, so in that sense it is a bit
different from India where the focus is on the communities. That means that
the link to household and village might not be as important, but the
mother-child link is probably important, and the data also belongs to the
reporting health facility (ward). So clients and health facilities own the
data, similar to the Zanzibar case. But here the tracking of clients over
time is important, as it is in India. Also here there is a clear need to
produce aggregated reports based on the patient-level data, and from the
forms provided by Tran the data elements for patient-level and routine seem
very similar, and again like in India the main difference with the data is
the owner, so I assume a lot of routine data and patient data can share the
same data element name.

Design choices:
Building on Abyot’s design, discussions we've had in Oslo and also the
summary above my feeling is that we can reuse existing design concepts like
data element, data set, and data entry form. We should probably
differentiate in the GUI between Patient Data Elements and Routine
(aggregated) Data Elements, but the same object seems to capture what we
need. Similarly all registers/forms seem possible to represent as data sets
and then if needed a custom data entry form can be designed on top of that.
This seems very similar to what we already have in DHIS2. The expressions
for how to generate aggregated data from patient data could fit into the
concept of calculated data elements, at least if we extend it a bit.

If we go for this approach and reuse data elements and sets then we need to
extend the dataset management functionality in order to specify what kind of
data that is captured with the dataset since data entry will be quite
different for patient and routine data and since we possibly need to use two
different data value objects for patient and routine. We could e.g. do like
1.4 and add a "data table" property to datasets where we can specify whether
it is patient or aggregated data (don't like to use routine as it doesn't
capture semi-permanent data).
Then when you open data entry and select a dataset the screen and procedures
will vary depending on what type of data that is going to be captured.

This means that we do not really need a new web module for meta data
management and data entry for patient data, but in stead can extend the
existing data dictionary and data entry modules. For the CBHIS work planner
functionality I assume we need a new web module. Not sure how smooth it will
work, but it could be an idea to have a global setting where the user can
enable/disable patient data, meaning that a system without patient data
enables would like pretty much like DHIS 2 today (using "Data Elements" in
stead of the two types which can be annoying to the users that are not using
this functionality).

Some complications from extending the use of the data element object would
be to filter out patient data in datamart, report tables and all places
where you only want to deal with normal aggregated data. I am not the one to
answer whether that will slow down the mentioned functionality or not, but I
guess that is something we need to look into.

I also proposed this approach off reusing existing dataelement object
a week or two back. You go a step further by suggesting a person
might be an orgunit. That's quite interesting! I had thought down to
the level of a household (the household being the sort of twighlight
zone between abstract and social organisation - complete with all its
address and family-relation greynesses).

But a person would need an extra field/attribute in the datavalue
model. If a person *is* an orgunit then I guess that problem could be
solved. Of course, given our recent updates, a person could then also
have a url as well which is fun. And having a url is not such a mad
thing - I believe the New Zealand eGovernment plan envisages exactly
that. Might not necessarily resolve to anything - but an interesting
placeholder. Also relations between persons are more complex and
transient than typically between clinics and the like. A problem to
solve ... and in terms of a demographic model I would still encourage
us to reuse something like openMRS rather than reinventing.

But the concern you raise is on filtering out in datamart etc. My own
sense is that the mere fact that person data and aggregate data might
share the same data model with datasets, dataelements and datavalues
this does not imply the datavalues have to (or even should) share the
same database or database table. So there is not necessarily an
impact on "slowing down".

Though if persons - or even households - are part of the orgunit tree
I think you will hit a crunch. We would almost definitely require a
separate orgunit table

Another complication I see from this would be the use of the same data
element for both patient-data and aggregated data. As explained above, the
meaning of the data is the same, it is simply the owner that is different
(further down the hierarchy), so it seems natural to allow this kind of
reuse. But how to we e.g. control that the aggregated data element is not
registered also in routine data collection for the same orgunits that are
also generating the same data from patient records? Maybe a new data element
property that defines whether it is generated or registered directly?
Obviously we need to do some thinking about this, but I think the general
idea is that it would be very good to be able to seamlessly zoom in and out
on data elements between aggregated and patient "orgunit" levels. That is
something which is really requested by various stakeholders in global
health.

Technologies
I agree with Lars that we should keep this process as simple and fast as
possible and therefore start by building on what we already have. My
scenario of reuse above also supports this.
Still I also agree with Bob that this is a chance to think new and look at
alternatives, but I think we should to it in gradual manner so that we do
not slow down the (functionality) development process. Struts 2 and Spring
Security seems like a good start to me. If we create a new branch in
launchpad for CBHIS from today’s/next week's or whatever trunk and start
coding on the new CBHIS functionality there we could safely start such a
process. I assume successful transitions to Struts2 etc could then be merged
into trunk along the way (somehow). Or?

I suspect Lars and Murod are in the best position to answer this. But
it sounds ok to me :slight_smile:

Cheers
Bob

···

2009/5/27 Ola Hodne Titlestad <olati@ifi.uio.no>:

best regards,
Ola Hodne Titlestad
HISP
University of Oslo

On Wed, May 27, 2009 at 3:10 PM, Ola Hodne Titlestad <olati@ifi.uio.no> > wrote:

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

_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

Dear Ola,

Thank you for the detailed description of the requirement you gave us from Zanzibar’s point of view. I also have taken a look to the requirement document from Vietnam.

And one concern I have is, to what extent are we pushing for a system focused on Patient data or history? I am aksing this because both from Zanzibar and Vietnam I see the patient being the central point. From both requirements the patient is the unique identifier in the whole business processing and for me this has a tendency more to patient record system than anyother system - aggregate or register (which is central in the CBHIS).

In the CBHIS, or registers, what we have is big books dedicated for specific programs – Birth Register, Death Register, ANC Register, … and individuals are ordinary instances in the respective programs - very much like a list of lines attributed to individuals. The way I see it we can model registers as datasets or advanced version of them and the specific items collected in the registers as dataelements (advanced, routine or patient whatever we call them) and then a link to individuals (we can call them person or patient). This approch I think is something inline with the current logic of DHIS2 – aggregate more of management information system than patient record.

Having said this, I have two questions one for Zanzibar and another one for Vietnam

Zanzibar: To what extent the document I attached (Maternal_Death_Auditing) fits into the requirement?

Vietnam: What is your assesment of OpenMRS for your requirement?

Thank you
Abyot.

Maternal_Death_Auditing.pdf (16.8 KB)

···

2009/5/27 Ola Hodne Titlestad olati@ifi.uio.no

Hi,

Abyot, Lars, Jørn and I have had some discussions in Oslo concerning the design of the CBHIS that I thought I would share with you before tomorrow’s call. These are my interpretations and views on what has been discussed and do not necessarily reflect what Abyot, Jørn and Lars thinks… Hope this will help to make tomorrow’s call more constructive.

**Summary of functional requirements:**I’ll do my best to provide a short summary of the three use cases we have seen so far from India, Vietnam and Zanzibar: Please fill in and correct me if needed.

India: The type of data captured very similar to routine data in the sense that it is basic health program data like “BCG vaccine given”, “DPT1 vaccine given” etc. BUT differs with regards to the owner of the data which are individual clients and households. In that sense the data elements are the same, but the “orgunits” are extended down to the lowest possible level, the individual. In addition there are requirements for a work planner system that helps to organise the out reach work of the health workers providing schedules and work plans on where to do household visits based on the data available (which chidren in the village are scheduled for DPT3 vaccine next week etc.).

There is a clear link to aggregated data as data elements can be derived directly from the household data (can even be the same data element), but aggregation is needed in order to analyse higher levels in the orgunit tree.

Zanzibar / DHIS 1.4 patient:
In this use case the data elements are also different from the routine as they are typically much more detailes than routine data, in a way zooming in on each case with more details. The orgunits are the same, but data is also belonging to individuals, although more as a reference for later lookup, not to keep track of patients/clients over time.

In this use case is is the details of each reported case that are important, not the name of the patient. Routine data are generated based on expressions and criteria to filter and count the detailed patient-level data.

Vietnam:
I have not fully grasped all the requirements here, but at first glance they seem quite similar to the Indian needs. The idea is for health programs to follow up individual clients (mothers and children) and register essential data on vaccination, ANC check-ups, deliveries. I know that e.g. in the big city of HCMC they want to have a central register with all pregnant mothers and I assume the same for newborn children, so in that sense it is a bit different from India where the focus is on the communities. That means that the link to household and village might not be as important, but the mother-child link is probably important, and the data also belongs to the reporting health facility (ward). So clients and health facilities own the data, similar to the Zanzibar case. But here the tracking of clients over time is important, as it is in India. Also here there is a clear need to produce aggregated reports based on the patient-level data, and from the forms provided by Tran the data elements for patient-level and routine seem very similar, and again like in India the main difference with the data is the owner, so I assume a lot of routine data and patient data can share the same data element name.

**Design choices:**Building on Abyot’s design, discussions we’ve had in Oslo and also the summary above my feeling is that we can reuse existing design concepts like data element, data set, and data entry form. We should probably differentiate in the GUI between Patient Data Elements and Routine (aggregated) Data Elements, but the same object seems to capture what we need. Similarly all registers/forms seem possible to represent as data sets and then if needed a custom data entry form can be designed on top of that. This seems very similar to what we already have in DHIS2. The expressions for how to generate aggregated data from patient data could fit into the concept of calculated data elements, at least if we extend it a bit.

If we go for this approach and reuse data elements and sets then we need to extend the dataset management functionality in order to specify what kind of data that is captured with the dataset since data entry will be quite different for patient and routine data and since we possibly need to use two different data value objects for patient and routine. We could e.g. do like 1.4 and add a “data table” property to datasets where we can specify whether it is patient or aggregated data (don’t like to use routine as it doesn’t capture semi-permanent data).

Then when you open data entry and select a dataset the screen and procedures will vary depending on what type of data that is going to be captured.

This means that we do not really need a new web module for meta data management and data entry for patient data, but in stead can extend the existing data dictionary and data entry modules. For the CBHIS work planner functionality I assume we need a new web module. Not sure how smooth it will work, but it could be an idea to have a global setting where the user can enable/disable patient data, meaning that a system without patient data enables would like pretty much like DHIS 2 today (using “Data Elements” in stead of the two types which can be annoying to the users that are not using this functionality).

Some complications from extending the use of the data element object would be to filter out patient data in datamart, report tables and all places where you only want to deal with normal aggregated data. I am not the one to answer whether that will slow down the mentioned functionality or not, but I guess that is something we need to look into.

Another complication I see from this would be the use of the same data element for both patient-data and aggregated data. As explained above, the meaning of the data is the same, it is simply the owner that is different (further down the hierarchy), so it seems natural to allow this kind of reuse. But how to we e.g. control that the aggregated data element is not registered also in routine data collection for the same orgunits that are also generating the same data from patient records? Maybe a new data element property that defines whether it is generated or registered directly? Obviously we need to do some thinking about this, but I think the general idea is that it would be very good to be able to seamlessly zoom in and out on data elements between aggregated and patient “orgunit” levels. That is something which is really requested by various stakeholders in global health.

TechnologiesI agree with Lars that we should keep this process as simple and fast as possible and therefore start by building on what we already have. My scenario of reuse above also supports this.
Still I also agree with Bob that this is a chance to think new and look at alternatives, but I think we should to it in gradual manner so that we do not slow down the (functionality) development process. Struts 2 and Spring Security seems like a good start to me. If we create a new branch in launchpad for CBHIS from today’s/next week’s or whatever trunk and start coding on the new CBHIS functionality there we could safely start such a process. I assume successful transitions to Struts2 etc could then be merged into trunk along the way (somehow). Or?

best regards,
Ola Hodne Titlestad
HISP
University of Oslo

On Wed, May 27, 2009 at 3:10 PM, Ola Hodne Titlestad olati@ifi.uio.no wrote:

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 datasetsThis 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 valuesEach 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 elementsIn 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.

ReportsThere 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.

  1. 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.
  2. 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 recordsPer 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/ExportJust 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


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Hi

Hi,

Abyot, Lars, Jørn and I have had some discussions in Oslo concerning the

design of the CBHIS that I thought I would share with you before tomorrow’s

call. These are my interpretations and views on what has been discussed and

do not necessarily reflect what Abyot, Jørn and Lars thinks… Hope this

will help to make tomorrow’s call more constructive.

Summary of functional requirements:

I’ll do my best to provide a short summary of the three use cases we have

seen so far from India, Vietnam and Zanzibar: Please fill in and correct me

if needed.

India: The type of data captured very similar to routine data in the sense

that it is basic health program data like “BCG vaccine given”, "DPT1 vaccine

given" etc. BUT differs with regards to the owner of the data which are

individual clients and households. In that sense the data elements are the

same, but the “orgunits” are extended down to the lowest possible level, the

individual. In addition there are requirements for a work planner system

that helps to organise the out reach work of the health workers providing

schedules and work plans on where to do household visits based on the data

available (which chidren in the village are scheduled for DPT3 vaccine next

week etc.).

There is a clear link to aggregated data as data elements can be derived

directly from the household data (can even be the same data element), but

aggregation is needed in order to analyse higher levels in the orgunit tree.

Zanzibar / DHIS 1.4 patient:

In this use case the data elements are also different from the routine as

they are typically much more detailes than routine data, in a way zooming in

on each case with more details. The orgunits are the same, but data is also

belonging to individuals, although more as a reference for later lookup, not

to keep track of patients/clients over time.

In this use case is is the details of each reported case that are important,

not the name of the patient. Routine data are generated based on expressions

and criteria to filter and count the detailed patient-level data.

Vietnam:

I have not fully grasped all the requirements here, but at first glance they

seem quite similar to the Indian needs. The idea is for health programs to

follow up individual clients (mothers and children) and register essential

data on vaccination, ANC check-ups, deliveries. I know that e.g. in the big

city of HCMC they want to have a central register with all pregnant mothers

and I assume the same for newborn children, so in that sense it is a bit

different from India where the focus is on the communities. That means that

the link to household and village might not be as important, but the

mother-child link is probably important, and the data also belongs to the

reporting health facility (ward). So clients and health facilities own the

data, similar to the Zanzibar case. But here the tracking of clients over

time is important, as it is in India. Also here there is a clear need to

produce aggregated reports based on the patient-level data, and from the

forms provided by Tran the data elements for patient-level and routine seem

very similar, and again like in India the main difference with the data is

the owner, so I assume a lot of routine data and patient data can share the

same data element name.

Design choices:

Building on Abyot’s design, discussions we’ve had in Oslo and also the

summary above my feeling is that we can reuse existing design concepts like

data element, data set, and data entry form. We should probably

differentiate in the GUI between Patient Data Elements and Routine

(aggregated) Data Elements, but the same object seems to capture what we

need. Similarly all registers/forms seem possible to represent as data sets

and then if needed a custom data entry form can be designed on top of that.

This seems very similar to what we already have in DHIS2. The expressions

for how to generate aggregated data from patient data could fit into the

concept of calculated data elements, at least if we extend it a bit.

If we go for this approach and reuse data elements and sets then we need to

extend the dataset management functionality in order to specify what kind of

data that is captured with the dataset since data entry will be quite

different for patient and routine data and since we possibly need to use two

different data value objects for patient and routine. We could e.g. do like

1.4 and add a “data table” property to datasets where we can specify whether

it is patient or aggregated data (don’t like to use routine as it doesn’t

capture semi-permanent data).

Then when you open data entry and select a dataset the screen and procedures

will vary depending on what type of data that is going to be captured.

This means that we do not really need a new web module for meta data

management and data entry for patient data, but in stead can extend the

existing data dictionary and data entry modules. For the CBHIS work planner

functionality I assume we need a new web module. Not sure how smooth it will

work, but it could be an idea to have a global setting where the user can

enable/disable patient data, meaning that a system without patient data

enables would like pretty much like DHIS 2 today (using “Data Elements” in

stead of the two types which can be annoying to the users that are not using

this functionality).

Some complications from extending the use of the data element object would

be to filter out patient data in datamart, report tables and all places

where you only want to deal with normal aggregated data. I am not the one to

answer whether that will slow down the mentioned functionality or not, but I

guess that is something we need to look into.

I also proposed this approach off reusing existing dataelement object

a week or two back. You go a step further by suggesting a person

might be an orgunit. That’s quite interesting! I had thought down to

the level of a household (the household being the sort of twighlight

zone between abstract and social organisation - complete with all its

address and family-relation greynesses).

hehe, I can see that my writing might have been misleading. I was not thinking of individuals as orgunits as such, but I was trying to explain how this patient/community data is different from “normal” data. With community systems the difference is that we zoom in on orguints and look at another more detailed patient level, and for the audits we zoom in on data elements and look at more detailed data there. That was my point. But conceotually a community client is an extension of the orgunit. Though I think we will be in trouble trying to map all indivisulas to orgunits and deal with migration etc. Anyway, the important thing will be able to group patient data by orgunit, that we register which orgunit the data/client belongs to.

Somehow we need to switch between two different sources of data; orguints and patients, also in reports etc. where that kind of zoom-in/zoom-out in desired.

But a person would need an extra field/attribute in the datavalue

model. If a person is an orgunit then I guess that problem could be

solved. Of course, given our recent updates, a person could then also

have a url as well which is fun. And having a url is not such a mad

thing - I believe the New Zealand eGovernment plan envisages exactly

that. Might not necessarily resolve to anything - but an interesting

placeholder. Also relations between persons are more complex and

transient than typically between clinics and the like. A problem to

solve … and in terms of a demographic model I would still encourage

us to reuse something like openMRS rather than reinventing.

But the concern you raise is on filtering out in datamart etc. My own

sense is that the mere fact that person data and aggregate data might

share the same data model with datasets, dataelements and datavalues

this does not imply the datavalues have to (or even should) share the

same database or database table. So there is not necessarily an

impact on “slowing down”.
Yes, I see that point. Agree that the data is the main difference here and glad if we can reuse data elements/sets/forms without disturbing other modules.

Though if persons - or even households - are part of the orgunit tree

I think you will hit a crunch. We would almost definitely require a

separate orgunit table
As I wrote above, the link between orgunit and patient must be loose, and in many cases come through the data.
But for comunity activity plannning I guess we need to identify which orguints are responsible for which households and clients?

···

2009/5/27 Bob Jolliffe bobjolliffe@gmail.com

2009/5/27 Ola Hodne Titlestad olati@ifi.uio.no:

Another complication I see from this would be the use of the same data

element for both patient-data and aggregated data. As explained above, the

meaning of the data is the same, it is simply the owner that is different

(further down the hierarchy), so it seems natural to allow this kind of

reuse. But how to we e.g. control that the aggregated data element is not

registered also in routine data collection for the same orgunits that are

also generating the same data from patient records? Maybe a new data element

property that defines whether it is generated or registered directly?

Obviously we need to do some thinking about this, but I think the general

idea is that it would be very good to be able to seamlessly zoom in and out

on data elements between aggregated and patient “orgunit” levels. That is

something which is really requested by various stakeholders in global

health.

Technologies

I agree with Lars that we should keep this process as simple and fast as

possible and therefore start by building on what we already have. My

scenario of reuse above also supports this.

Still I also agree with Bob that this is a chance to think new and look at

alternatives, but I think we should to it in gradual manner so that we do

not slow down the (functionality) development process. Struts 2 and Spring

Security seems like a good start to me. If we create a new branch in

launchpad for CBHIS from today’s/next week’s or whatever trunk and start

coding on the new CBHIS functionality there we could safely start such a

process. I assume successful transitions to Struts2 etc could then be merged

into trunk along the way (somehow). Or?

I suspect Lars and Murod are in the best position to answer this. But

it sounds ok to me :slight_smile:

Cheers

Bob

best regards,

Ola Hodne Titlestad

HISP

University of Oslo

On Wed, May 27, 2009 at 3:10 PM, Ola Hodne Titlestad olati@ifi.uio.no > > > wrote:

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.

  1. 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.

  1. 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


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Dear Ola,

Thank you for the detailed description of the requirement you gave us from Zanzibar’s point of view. I also have taken a look to the requirement document from Vietnam.

And one concern I have is, to what extent are we pushing for a system focused on Patient data or history? I am aksing this because both from Zanzibar and Vietnam I see the patient being the central point. From both requirements the patient is the unique identifier in the whole business processing and for me this has a tendency more to patient record system than anyother system - aggregate or register (which is central in the CBHIS).

For the case of Zanzibar or DHIS 1.4 Patient module functionality the patient history is not at all important, and the central issue are the detailed data about each case, not the patient itself. So there you misunderstood. Remember that DHIS 1.4 patient module which is used in Zanzibar is a very simplistic case-based system with no patient record/history tracking and almost complete reuse of the normal/aggregated data DHIS design.

In the CBHIS, or registers, what we have is big books dedicated for specific programs – Birth Register, Death Register, ANC Register, … and individuals are ordinary instances in the respective programs - very much like a list of lines attributed to individuals. The way I see it we can model registers as datasets or advanced version of them and the specific items collected in the registers as dataelements (advanced, routine or patient whatever we call them) and then a link to individuals (we can call them person or patient). This approch I think is something inline with the current logic of DHIS2 – aggregate more of management information system than patient record.

Having said this, I have two questions one for Zanzibar and another one for Vietnam

Zanzibar: To what extent the document I attached (Maternal_Death_Auditing) fits into the requirement?
Your attached form fits this type of scenarios yes. The only difference is that in Zanzibar they collect even more details about each death so a line listing design of the form is not suitable.
In stead they use a custom form, much like any other custom form in DHIS to register data. I think the requirements from India and Zanzibar are very similar and that the difference is more on the use of the data. A community focus leads to the need to have an activity planner which they do not need in Zanzibar at the moment, and they are also not so much interested in tracing down the village and household of the maternal deaths or other vital events they register. But that is just the level of detail, the overall needs are the same, and maybe in the future they will need to track households in Znz as well.

Vietnam: What is your assesment of OpenMRS for your requirement?
I was thinking the same this morning when I read these requirements. This seems more comprehensive in terms of tracking patients and their data over time and I would also suggest looking into OpenMRS as an option here. Dealing with case-based data lin audits or basic health program needs in communities at the level described in Zanzibar and India is one thing, but this, although I do not fully grasp the requirements, seems to me to be closer to OpenMRS than DHIS. We need to be a bit careful with regards to how far we stretch DHIS in the direction of electronic patient records, in order not to introduce unwanted complexity to the system we have today, and also in terms of seeing ourselves as one of many actors in FOSS for global health community and therefore try to build alliances with other actors like OpenMRS in situations where they have more suitable solutions. This might be one.

Look forward to tomorrow’s call.
Remember to reply to Abyot’s invitation and share your SkypeIDs, that will make it a lot easier to iniatite the call.

Ola

···

2009/5/27 Abyot Gizaw abyota@gmail.com

Thank you
Abyot.

2009/5/27 Ola Hodne Titlestad olati@ifi.uio.no

Hi,

Abyot, Lars, Jørn and I have had some discussions in Oslo concerning the design of the CBHIS that I thought I would share with you before tomorrow’s call. These are my interpretations and views on what has been discussed and do not necessarily reflect what Abyot, Jørn and Lars thinks… Hope this will help to make tomorrow’s call more constructive.

**Summary of functional requirements:**I’ll do my best to provide a short summary of the three use cases we have seen so far from India, Vietnam and Zanzibar: Please fill in and correct me if needed.

India: The type of data captured very similar to routine data in the sense that it is basic health program data like “BCG vaccine given”, “DPT1 vaccine given” etc. BUT differs with regards to the owner of the data which are individual clients and households. In that sense the data elements are the same, but the “orgunits” are extended down to the lowest possible level, the individual. In addition there are requirements for a work planner system that helps to organise the out reach work of the health workers providing schedules and work plans on where to do household visits based on the data available (which chidren in the village are scheduled for DPT3 vaccine next week etc.).

There is a clear link to aggregated data as data elements can be derived directly from the household data (can even be the same data element), but aggregation is needed in order to analyse higher levels in the orgunit tree.

Zanzibar / DHIS 1.4 patient:
In this use case the data elements are also different from the routine as they are typically much more detailes than routine data, in a way zooming in on each case with more details. The orgunits are the same, but data is also belonging to individuals, although more as a reference for later lookup, not to keep track of patients/clients over time.

In this use case is is the details of each reported case that are important, not the name of the patient. Routine data are generated based on expressions and criteria to filter and count the detailed patient-level data.

Vietnam:
I have not fully grasped all the requirements here, but at first glance they seem quite similar to the Indian needs. The idea is for health programs to follow up individual clients (mothers and children) and register essential data on vaccination, ANC check-ups, deliveries. I know that e.g. in the big city of HCMC they want to have a central register with all pregnant mothers and I assume the same for newborn children, so in that sense it is a bit different from India where the focus is on the communities. That means that the link to household and village might not be as important, but the mother-child link is probably important, and the data also belongs to the reporting health facility (ward). So clients and health facilities own the data, similar to the Zanzibar case. But here the tracking of clients over time is important, as it is in India. Also here there is a clear need to produce aggregated reports based on the patient-level data, and from the forms provided by Tran the data elements for patient-level and routine seem very similar, and again like in India the main difference with the data is the owner, so I assume a lot of routine data and patient data can share the same data element name.

**Design choices:**Building on Abyot’s design, discussions we’ve had in Oslo and also the summary above my feeling is that we can reuse existing design concepts like data element, data set, and data entry form. We should probably differentiate in the GUI between Patient Data Elements and Routine (aggregated) Data Elements, but the same object seems to capture what we need. Similarly all registers/forms seem possible to represent as data sets and then if needed a custom data entry form can be designed on top of that. This seems very similar to what we already have in DHIS2. The expressions for how to generate aggregated data from patient data could fit into the concept of calculated data elements, at least if we extend it a bit.

If we go for this approach and reuse data elements and sets then we need to extend the dataset management functionality in order to specify what kind of data that is captured with the dataset since data entry will be quite different for patient and routine data and since we possibly need to use two different data value objects for patient and routine. We could e.g. do like 1.4 and add a “data table” property to datasets where we can specify whether it is patient or aggregated data (don’t like to use routine as it doesn’t capture semi-permanent data).

Then when you open data entry and select a dataset the screen and procedures will vary depending on what type of data that is going to be captured.

This means that we do not really need a new web module for meta data management and data entry for patient data, but in stead can extend the existing data dictionary and data entry modules. For the CBHIS work planner functionality I assume we need a new web module. Not sure how smooth it will work, but it could be an idea to have a global setting where the user can enable/disable patient data, meaning that a system without patient data enables would like pretty much like DHIS 2 today (using “Data Elements” in stead of the two types which can be annoying to the users that are not using this functionality).

Some complications from extending the use of the data element object would be to filter out patient data in datamart, report tables and all places where you only want to deal with normal aggregated data. I am not the one to answer whether that will slow down the mentioned functionality or not, but I guess that is something we need to look into.

Another complication I see from this would be the use of the same data element for both patient-data and aggregated data. As explained above, the meaning of the data is the same, it is simply the owner that is different (further down the hierarchy), so it seems natural to allow this kind of reuse. But how to we e.g. control that the aggregated data element is not registered also in routine data collection for the same orgunits that are also generating the same data from patient records? Maybe a new data element property that defines whether it is generated or registered directly? Obviously we need to do some thinking about this, but I think the general idea is that it would be very good to be able to seamlessly zoom in and out on data elements between aggregated and patient “orgunit” levels. That is something which is really requested by various stakeholders in global health.

TechnologiesI agree with Lars that we should keep this process as simple and fast as possible and therefore start by building on what we already have. My scenario of reuse above also supports this.
Still I also agree with Bob that this is a chance to think new and look at alternatives, but I think we should to it in gradual manner so that we do not slow down the (functionality) development process. Struts 2 and Spring Security seems like a good start to me. If we create a new branch in launchpad for CBHIS from today’s/next week’s or whatever trunk and start coding on the new CBHIS functionality there we could safely start such a process. I assume successful transitions to Struts2 etc could then be merged into trunk along the way (somehow). Or?

best regards,
Ola Hodne Titlestad
HISP
University of Oslo

On Wed, May 27, 2009 at 3:10 PM, Ola Hodne Titlestad olati@ifi.uio.no wrote:

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 datasetsThis 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 valuesEach 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 elementsIn 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.

ReportsThere 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.

  1. 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.
  2. 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 recordsPer 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/ExportJust 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


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Hi

> Hi,
>
> Abyot, Lars, Jørn and I have had some discussions in Oslo concerning the
> design of the CBHIS that I thought I would share with you before
> tomorrow's
> call. These are my interpretations and views on what has been discussed
> and
> do not necessarily reflect what Abyot, Jørn and Lars thinks... Hope this
> will help to make tomorrow's call more constructive.
>
> Summary of functional requirements:
> I'll do my best to provide a short summary of the three use cases we
> have
> seen so far from India, Vietnam and Zanzibar: Please fill in and correct
> me
> if needed.
>
> India: The type of data captured very similar to routine data in the
> sense
> that it is basic health program data like "BCG vaccine given", "DPT1
> vaccine
> given" etc. BUT differs with regards to the owner of the data which are
> individual clients and households. In that sense the data elements are
> the
> same, but the "orgunits" are extended down to the lowest possible level,
> the
> individual. In addition there are requirements for a work planner system
> that helps to organise the out reach work of the health workers
> providing
> schedules and work plans on where to do household visits based on the
> data
> available (which chidren in the village are scheduled for DPT3 vaccine
> next
> week etc.).
> There is a clear link to aggregated data as data elements can be derived
> directly from the household data (can even be the same data element),
> but
> aggregation is needed in order to analyse higher levels in the orgunit
> tree.
>
>
> Zanzibar / DHIS 1.4 patient:
> In this use case the data elements are also different from the routine
> as
> they are typically much more detailes than routine data, in a way
> zooming in
> on each case with more details. The orgunits are the same, but data is
> also
> belonging to individuals, although more as a reference for later lookup,
> not
> to keep track of patients/clients over time.
> In this use case is is the details of each reported case that are
> important,
> not the name of the patient. Routine data are generated based on
> expressions
> and criteria to filter and count the detailed patient-level data.
>
> Vietnam:
> I have not fully grasped all the requirements here, but at first glance
> they
> seem quite similar to the Indian needs. The idea is for health programs
> to
> follow up individual clients (mothers and children) and register
> essential
> data on vaccination, ANC check-ups, deliveries. I know that e.g. in the
> big
> city of HCMC they want to have a central register with all pregnant
> mothers
> and I assume the same for newborn children, so in that sense it is a bit
> different from India where the focus is on the communities. That means
> that
> the link to household and village might not be as important, but the
> mother-child link is probably important, and the data also belongs to
> the
> reporting health facility (ward). So clients and health facilities own
> the
> data, similar to the Zanzibar case. But here the tracking of clients
> over
> time is important, as it is in India. Also here there is a clear need to
> produce aggregated reports based on the patient-level data, and from the
> forms provided by Tran the data elements for patient-level and routine
> seem
> very similar, and again like in India the main difference with the data
> is
> the owner, so I assume a lot of routine data and patient data can share
> the
> same data element name.
>
>
> Design choices:
> Building on Abyot’s design, discussions we've had in Oslo and also the
> summary above my feeling is that we can reuse existing design concepts
> like
> data element, data set, and data entry form. We should probably
> differentiate in the GUI between Patient Data Elements and Routine
> (aggregated) Data Elements, but the same object seems to capture what we
> need. Similarly all registers/forms seem possible to represent as data
> sets
> and then if needed a custom data entry form can be designed on top of
> that.
> This seems very similar to what we already have in DHIS2. The
> expressions
> for how to generate aggregated data from patient data could fit into the
> concept of calculated data elements, at least if we extend it a bit.
>
> If we go for this approach and reuse data elements and sets then we need
> to
> extend the dataset management functionality in order to specify what
> kind of
> data that is captured with the dataset since data entry will be quite
> different for patient and routine data and since we possibly need to use
> two
> different data value objects for patient and routine. We could e.g. do
> like
> 1.4 and add a "data table" property to datasets where we can specify
> whether
> it is patient or aggregated data (don't like to use routine as it
> doesn't
> capture semi-permanent data).
> Then when you open data entry and select a dataset the screen and
> procedures
> will vary depending on what type of data that is going to be captured.
>
> This means that we do not really need a new web module for meta data
> management and data entry for patient data, but in stead can extend the
> existing data dictionary and data entry modules. For the CBHIS work
> planner
> functionality I assume we need a new web module. Not sure how smooth it
> will
> work, but it could be an idea to have a global setting where the user
> can
> enable/disable patient data, meaning that a system without patient data
> enables would like pretty much like DHIS 2 today (using "Data Elements"
> in
> stead of the two types which can be annoying to the users that are not
> using
> this functionality).
>
> Some complications from extending the use of the data element object
> would
> be to filter out patient data in datamart, report tables and all places
> where you only want to deal with normal aggregated data. I am not the
> one to
> answer whether that will slow down the mentioned functionality or not,
> but I
> guess that is something we need to look into.

I also proposed this approach off reusing existing dataelement object
a week or two back. You go a step further by suggesting a person
might be an orgunit. That's quite interesting! I had thought down to
the level of a household (the household being the sort of twighlight
zone between abstract and social organisation - complete with all its
address and family-relation greynesses).

hehe, I can see that my writing might have been misleading. I was not
thinking of individuals as orgunits as such, but I was trying to explain how
this patient/community data is different from "normal" data.

Its not necessarily as whacky as it sounds. I guess if you think of
the base class, source, rather than orgunit it can make sense. And
without it you do need to modify the datavalue to indicate the
patientId.

Bob.

···

2009/5/27 Ola Hodne Titlestad <olati@ifi.uio.no>:

2009/5/27 Bob Jolliffe <bobjolliffe@gmail.com>

2009/5/27 Ola Hodne Titlestad <olati@ifi.uio.no>:

With community
systems the difference is that we zoom in on orguints and look at another
more detailed patient level, and for the audits we zoom in on data elements
and look at more detailed data there. That was my point. But conceotually a
community client is an extension of the orgunit. Though I think we will be
in trouble trying to map all indivisulas to orgunits and deal with migration
etc. Anyway, the important thing will be able to group patient data by
orgunit, that we register which orgunit the data/client belongs to.
Somehow we need to switch between two different sources of data; orguints
and patients, also in reports etc. where that kind of zoom-in/zoom-out in
desired.

But a person would need an extra field/attribute in the datavalue
model. If a person *is* an orgunit then I guess that problem could be
solved. Of course, given our recent updates, a person could then also
have a url as well which is fun. And having a url is not such a mad
thing - I believe the New Zealand eGovernment plan envisages exactly
that. Might not necessarily resolve to anything - but an interesting
placeholder. Also relations between persons are more complex and
transient than typically between clinics and the like. A problem to
solve ... and in terms of a demographic model I would still encourage
us to reuse something like openMRS rather than reinventing.

But the concern you raise is on filtering out in datamart etc. My own
sense is that the mere fact that person data and aggregate data might
share the same data model with datasets, dataelements and datavalues
this does not imply the datavalues have to (or even should) share the
same database or database table. So there is not necessarily an
impact on "slowing down".

Yes, I see that point. Agree that the data is the main difference here and
glad if we can reuse data elements/sets/forms without disturbing other
modules.

Though if persons - or even households - are part of the orgunit tree
I think you will hit a crunch. We would almost definitely require a
separate orgunit table

As I wrote above, the link between orgunit and patient must be loose, and in
many cases come through the data.
But for comunity activity plannning I guess we need to identify which
orguints are responsible for which households and clients?

> Another complication I see from this would be the use of the same data
> element for both patient-data and aggregated data. As explained above,
> the
> meaning of the data is the same, it is simply the owner that is
> different
> (further down the hierarchy), so it seems natural to allow this kind of
> reuse. But how to we e.g. control that the aggregated data element is
> not
> registered also in routine data collection for the same orgunits that
> are
> also generating the same data from patient records? Maybe a new data
> element
> property that defines whether it is generated or registered directly?
> Obviously we need to do some thinking about this, but I think the
> general
> idea is that it would be very good to be able to seamlessly zoom in and
> out
> on data elements between aggregated and patient "orgunit" levels. That
> is
> something which is really requested by various stakeholders in global
> health.
>
> Technologies
> I agree with Lars that we should keep this process as simple and fast as
> possible and therefore start by building on what we already have. My
> scenario of reuse above also supports this.
> Still I also agree with Bob that this is a chance to think new and look
> at
> alternatives, but I think we should to it in gradual manner so that we
> do
> not slow down the (functionality) development process. Struts 2 and
> Spring
> Security seems like a good start to me. If we create a new branch in
> launchpad for CBHIS from today’s/next week's or whatever trunk and start
> coding on the new CBHIS functionality there we could safely start such a
> process. I assume successful transitions to Struts2 etc could then be
> merged
> into trunk along the way (somehow). Or?

I suspect Lars and Murod are in the best position to answer this. But
it sounds ok to me :slight_smile:

Cheers
Bob

>
> best regards,
> Ola Hodne Titlestad
> HISP
> University of Oslo
>
>
> On Wed, May 27, 2009 at 3:10 PM, Ola Hodne Titlestad <olati@ifi.uio.no> >> > wrote:
>>
>> 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
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to : dhis2-devs@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help : https://help.launchpad.net/ListHelp
>
>

hehe, I can see that my writing might have been misleading. I was not

thinking of individuals as orgunits as such, but I was trying to explain how

this patient/community data is different from “normal” data.

Its not necessarily as whacky as it sounds. I guess if you think of

the base class, source, rather than orgunit it can make sense. And

without it you do need to modify the datavalue to indicate the

patientId.

After all the DataValue was designed to allow for multiple implementations of Source, this might be a viable option…

Yes, but patient data values will still need to reference patient and dataset and need encryption.

···

2009/5/27 Lars Helge Øverland larshelge@gmail.com

hehe, I can see that my writing might have been misleading. I was not

thinking of individuals as orgunits as such, but I was trying to explain how

this patient/community data is different from “normal” data.

Its not necessarily as whacky as it sounds. I guess if you think of

the base class, source, rather than orgunit it can make sense. And

without it you do need to modify the datavalue to indicate the

patientId.

After all the DataValue was designed to allow for multiple implementations of Source, this might be a viable option…

The datavalues don't necessarily need encryption. Just the identifying data.

I think currently we don't explicitly reference dataset when we store
a datavalue. We reference the dataelement, the period and the source.
The dataset is sort of inferred from the dataelement-source
combination.

If the source refers to facility then we would need an extra field for
personID. This would break the orthogonality of DataValue and
personDataValue which might be unavoidable, but would be a pity.

Treating the person as the source (note Abyot - I am very deliberately
not saying patient!) means that the link back to the relevant
collecting facility would have to be done through the organisation
hierarchy. Back through the household and up. Which is ok, but might
be tricky if that same hierarchy is split in two.

But one huge benefit of the person as source is that these persons
will never migrate from their source :slight_smile:

But they will migrate between households and between facilities.
Perhaps the model of OpenMRS (with as many addresses as you like) can
help here. Particulalry if we additionally have a date related to the
address - so we have 'Bob Jolliffe, last known in household/family XXX
at address YYY'. formerly of household/family WWW at address ZZZ'
etc. This history also helps to bolster confidence in the reliability
of identity.

Cheers
Bob

···

2009/5/27 Ola Hodne Titlestad <olati@ifi.uio.no>:

2009/5/27 Lars Helge Øverland <larshelge@gmail.com>

>
> hehe, I can see that my writing might have been misleading. I was not
> thinking of individuals as orgunits as such, but I was trying to
> explain how
> this patient/community data is different from "normal" data.

Its not necessarily as whacky as it sounds. I guess if you think of
the base class, source, rather than orgunit it can make sense. And
without it you do need to modify the datavalue to indicate the
patientId.

After all the DataValue was designed to allow for multiple implementations
of Source, this might be a viable option...

Yes, but patient data values will still need to reference patient and
dataset and need encryption.