dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Can someone define what exactly is an onChange period type?  Its a
term I have heard referred to a lot but I must confess I don't know if
I properly understand what it means.  Do we simply mean an arbitrary
period of time (without frequency) ie. it has start and end date only,
but no inherent frequency characteristic?  So start date would equal
the end date of the previous OnChange period for the same series of
datavalues.  Or is it an instant ie. an observation captured at a
moment in time with no inherent interval implied?  So
startdate=enddate?

One case I recall hearing onChange periods being discussed was regard
staffing data in the context of data import from iHRIS.  The number of
doctors might change infrequently so we might capture number of
doctors only when there is a change, rather than capturing the same
numbers each month.  Either way it raises an interesting problem. I
think we define the aggregation "operator" (sum, average etc) per data
element.  But it seems to me, looking at this particular example, that
you would actually want to aggregate differently depending on which
axis (time and space) that you were aggregating along.  So for example
if I have datavalues for "number of doctors" which I collect on a
monthly report, it makes sense to sum across the spatial axis and
average across the time axis

               clinicA     clinicB   DistrictTotal
Jan           5              7            12
Feb           5              6            11
Mar           5              5            10

Quarter      5             6             11

Maybe there are other such cases where the aggregation operator would
differ across different axes.  So there are maybe two ways to
rationalise this: one is to not capture the data monthly, but rather
"onChange".  This does have an implication for things like monthly
data collection instruments, because I suspect frequently there will
be a requirement to capture such data routinely.  The other is for the
dataelement to capture the change rather than the cumulative count -
like we would do with "new malaria cases" for example.  In this case
we'd capture "new doctors".  In that case we could sum across both
axes and get a sensible result, but one which would only be useful
with a sort of opening balance for the dataelement.   So it is not so
much the period type which is onChange but the dataValue type.  The
datavalue either reflects what has happened within that period or what
the cumulative status is at the end of that period.

This is maybe confusing two related issues, but the other approach
which comes to mind is to have two aggregation operators for the data
element - the time aggregation operator and the space aggregation
operator.  This might lead a simple way out of the contradictions and
complications above.  For many, perhaps most, these would both be
"sum".  But for others, like the above, we would "sum" over space and
"average" over time.  I am sure there might be other examples where
the reverse is true.

I am also sure these are all well known and well solved problems, so
apologies if I am being ignorant.

Cheers
Bob

Philosophical aside: Frederick Engels in Anti-Durhring, defines time
as that quantity required in order for things to change.  I always
like that definition :-)


2010/11/18 Lars Helge Øverland <larshelge@xxxxxxxxx>:
> The aggregation routines are using start- and end-dates for the periods
> associated with the datavalues only, so the output tools should handle it
> just fine.
> Lars
>
> 2010/11/18 Jason Pickering <jason.p.pickering@xxxxxxxxx>
>>
>> Tricky indeed. This is a workaround for the import, but what happens
>> to all the data values when we try and use them?
>>
>> 2010/11/18 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>> > This is a tricky one. We don't support any behavior related to on-change
>> > period type in DHIS 2 so we decided to remove it from the system. But
>> > DHIS
>> > 1.4 has it and uses that period type during import. A workaround is to
>> > insert a row "OnChange" in the periodtype table before doing import from
>> > 1.4
>> > Lars
>> >
>> > On Fri, Nov 5, 2010 at 1:04 PM, Jason Pickering
>> > <jason.p.pickering@xxxxxxxxx> wrote:
>> >>
>> >> Using the 2.0.5 release branch with Postgres, importing data from 1.4
>> >> which has an "OnChange" period type. The import seems to choke on
>> >> this.
>> >>
>> >> Does this periodtype exist in 2.0?
>> >>
>> >> Regards,
>> >> Jason
>> >>
>> >>
>> >> --
>> >> Jason P. Pickering
>> >> email: jason.p.pickering@xxxxxxxxx
>> >> tel:+260968395190
>> >>
>> >> _______________________________________________
>> >> 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
>> >
>> >
>>
>>
>>
>> --
>> Jason P. Pickering
>> email: jason.p.pickering@xxxxxxxxx
>> tel:+260968395190
>
>
> _______________________________________________
> 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
>
>