dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Hi

2009/5/27 Ola Hodne Titlestad <olati@xxxxxxxxxx>:
> 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 :-)

Cheers
Bob

>
> best regards,
> Ola Hodne Titlestad
> HISP
> University of Oslo
>
>
> On Wed, May 27, 2009 at 3:10 PM, Ola Hodne Titlestad <olati@xxxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>