dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

2010/6/29 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>
>
> On Mon, Jun 28, 2010 at 2:43 PM, Jason Pickering
> <jason.p.pickering@xxxxxxxxx> wrote:
>>
>> Hi. I agree and here is the use case.
>>
>> Data sets are essentially transient collections of data elements. In
>> Zambia, data used to be collected quarterly and was disaggregated by
>> Under 5 and Over 5. It is now collected monthly and by Under 1, 1-5
>> and Over 5. In theory, this phenomenn (which is fairly common, i.e.
>> changing of periodicity and disaggregation) should be able to be
>> represented by two separate data sets. This is essentially what we
>> have done now as I am able to assign different period types to
>> different datasets with the same data element. But because of the
>> inability to assign multiple category combos to a data element, I have
>> left all of the data elements as non-multidimensional data elements,
>> as I cannot represent the change in disaggregation over time.
>>
>> Having the ability to associate a data element with a data set (with a
>> given periodicity), assigning a data element to this data set, and
>> then assigning a category combo to the data element within that data
>> set (thus, a composite key between DE, catcombo and dataset) would
>> solve this problem. It is not clear to me either, even with the
>> current state of the data value table why this could not be possible
>> from the data model side.
>>
>
> Moving the CategoryCombo association from DataElement to Section might not
> be a bad idea, and doesn't sound too invasive. I think it has to be Section
> - not DataSet - since we after the current modification can have multiple
> Sections in a DataSet and each section can have a CategoryCombo.
> I think Jasons issue is slightly different. Seeing historical data when
> disaggregation has changed will always be an issue. In cases where a certain
> disaggregation is followed by a more fine-grained disaggregation (like 0-5,
> 5+ to 0-1, 1-5, 5+), I cannot really see how you can present the historical
> data (eg for 0-1).
> Lars

True.  But there is some rolling up which could be done.  For example
a simple implementation could always present historical data for the
total of the category.  A smarter implementation (admittedly much
smarter) could present historical data for 0-5.  But mostly I think it
is a simplification.  We need to attach a categorycombo to a section
anyway.  The logic maintaining the categorycombo link to a dataelement
and then ensure that only dataelements of the right categorycombo are
fitted into the right sections becomes redundandant.  As you say I
don't think its too invasive (it doesn't change the way datavalues are
stored) but probably also not a priority.

Regards
Bob

>>
>> Regards,
>> Jason
>>
>>
>> On Mon, Jun 28, 2010 at 12:23 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>> wrote:
>> > 2010/6/27 Jason Pickering <jason.p.pickering@xxxxxxxxx>:
>> >> Understood, but then this would require a complete overhaul of the
>> >> data model. If you look at the data value table, there are separate
>> >> keys for dataelementid and periodid, which implies that data values
>> >> can be observed in multiple places over multiple time periods (which
>> >> may themselves have different durations). This seems logical and
>> >> certainly reasonable. Otherwise, there would need to be an association
>> >> between a given data element and a given periodicity type, where now
>> >> the association is between a data set and a periodicity type. A given
>> >> dataset would thus derive its periodicity from a data element, whose
>> >> association would need to be specifically set when creating the data
>> >> element, and not the other way around.
>> >>
>> >> I would strongly urge that it be best avoided, and or implemented
>> >> specifically on a local branch for the SA team.
>> >
>> > Reading through these mails and looking at the datalement type,  I
>> > can't help feeling that the same argument also applies to the
>> > categorycombo (disaggregation, key family ...).  Just as a dataelement
>> > should not inherently be tied to a periodicity neither should it
>> > inherently be tied to a categorycombo.  I can't really see a good
>> > reason for it other than it may have looked simpler at the time.  Like
>> > the periodicity, the categorycombo can be determined by the dataset
>> > (or maybe more accurately - the section of the dataset) in which the
>> > dataelement is used.  Probably this is an aside and I don't really
>> > have the real use cases to back it up but I suspect it results in a
>> > simplification and increased flexibility so its a thought to keep in
>> > mind.
>> >
>> > Regards
>> > Bob
>> >
>> >>
>> >> Regards,
>> >> Jason
>> >>
>> >>
>> >> 2010/6/27 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>> >>>
>> >>>
>> >>> On Sun, Jun 27, 2010 at 7:15 AM, Jason Pickering
>> >>> <jason.p.pickering@xxxxxxxxx> wrote:
>> >>>>
>> >>>> Hi Lars,
>> >>>> This bug has been troubling me since I saw the report but it has
>> >>>> taken
>> >>>> a few walks in the woods to figure out why. I am not comfortable with
>> >>>> it being implemented and let me try and outline my argument.
>> >>>>
>> >>>> We are planning in Zambia to pilot the DHIS mobile app in certain
>> >>>> districts. Community health workers will report certain data elements
>> >>>> (e.g. Number of cases of clinical malaria under 1)  on a weekly
>> >>>> basis.
>> >>>> This same data element is reported on a monthly basis at the health
>> >>>> facility. Each community health worker will be attached to a health
>> >>>> center. Therefore the monthly total for a given health facility
>> >>>> should
>> >>>> be the number of cases observed at the health facility itself
>> >>>> (monthly) plus the number of cases observed by a CHW (weekly). As it
>> >>>> has been made clear by Ola several times, one can create any number
>> >>>> of
>> >>>> datasets, and associate a certain periodicity with them. The
>> >>>> periodicity is thus associated with the data set and not the data
>> >>>> element itself.
>> >>>>
>> >>>> This is really going to cause huge problems for us in particular, as
>> >>>> we have certain data elements, which in the past have been collected
>> >>>> quarterly, but which are now collected monthly. They exist in
>> >>>> different data sets with different periodicities.
>> >>>>
>> >>>> Could you provide more detail as to why this should not be allowed?
>> >>>>
>> >>>
>> >>> In this case its just a matter of conflicting wishes :-) The SA team
>> >>> is used
>> >>> to having an explicit period type for each data element and wanted
>> >>> this
>> >>> implemented. But since we currently are allowing data elements to
>> >>> appear in
>> >>> multiple datasets with different period types (as you point out) and
>> >>> it will
>> >>> cause you trouble we should maybe avoid it.
>> >>> Lars
>> >>>
>> >>>>
>> >>>> Regards,
>> >>>> Jason
>> >>>
>> >>>
>> >>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> 2010/6/26 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>> >>>> > On Tue, Jun 22, 2010 at 8:22 AM, Thu Tran
>> >>>> > <tran.hispvietnam@xxxxxxxxx>wrote:
>> >>>> >
>> >>>> >> Hi Lars,
>> >>>> >>
>> >>>> >> I'm busy to check database in Ho Chi Minh City. I didn't remember
>> >>>> >> to do
>> >>>> >> your
>> >>>> >> bugs. I'm so sorry.
>> >>>> >>
>> >>>> >> I sent the patch file for this bug to you. Please check it. Thank
>> >>>> >> you
>> >>>> >> very
>> >>>> >> much.
>> >>>> >>
>> >>>> >>
>> >>>> > Hi Tran, sorry I can not seem to find this patch, can you please
>> >>>> > re-send
>> >>>> > it?
>> >>>> >
>> >>>> > cheers Lars
>> >>>> >
>> >>>> >
>> >>>> >> Best regards,
>> >>>> >> ================================
>> >>>> >> Châu Thu Trân
>> >>>> >> HISP Viet Nam
>> >>>> >> Email: tran.hispvietnam@xxxxxxxxx
>> >>>> >> Cell phone: +84 97 324 1542
>> >>>> >> ================================
>> >>>> >>
>> >>>> >>
>> >>>> >> 2010/6/21 Lars Helge Øverland <larshelge@xxxxxxxxx>
>> >>>> >>
>> >>>> >> > ** Changed in: dhis2
>> >>>> >> >     Assignee: Thu Tran (tran-hispvietnam) => Thanh Tri Tran
>> >>>> >> > (tranthanhtri84)
>> >>>> >> >
>> >>>> >> > --
>> >>>> >> > Data element period not enforced with data set
>> >>>> >> > https://bugs.launchpad.net/bugs/589776
>> >>>> >> > You received this bug notification because you are a bug
>> >>>> >> > assignee.
>> >>>> >> >
>> >>>> >> > Status in DHIS 2 - District Health Information Software:
>> >>>> >> > Confirmed
>> >>>> >> >
>> >>>> >> > Bug description:
>> >>>> >> > It is possible to add a data element to a data set even if the
>> >>>> >> > data
>> >>>> >> element
>> >>>> >> > is a member of another data set with a different period type
>> >>>> >> > than
>> >>>> >> > this
>> >>>> >> one.
>> >>>> >> > This should not be allowed.
>> >>>> >> >
>> >>>> >> > We should filter out data elements with a different period type
>> >>>> >> > (member
>> >>>> >> of
>> >>>> >> > data sets with different period type) when creating and updating
>> >>>> >> > new
>> >>>> >> > data
>> >>>> >> > sets.
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >>
>> >>>> >>
>> >>>> >> ** Attachment added: "patch.diff"
>> >>>> >>   http://launchpadlibrarian.net/50720647/patch.diff
>> >>>> >>
>> >>>> >> --
>> >>>> >> Data element period not enforced with data set
>> >>>> >> https://bugs.launchpad.net/bugs/589776
>> >>>> >> You received this bug notification because you are a direct
>> >>>> >> subscriber
>> >>>> >> of the bug.
>> >>>> >>
>> >>>> >> Status in DHIS 2 - District Health Information Software: Confirmed
>> >>>> >>
>> >>>> >> Bug description:
>> >>>> >> It is possible to add a data element to a data set even if the
>> >>>> >> data
>> >>>> >> element
>> >>>> >> is a member of another data set with a different period type than
>> >>>> >> this
>> >>>> >> one.
>> >>>> >> This should not be allowed.
>> >>>> >>
>> >>>> >> We should filter out data elements with a different period type
>> >>>> >> (member
>> >>>> >> of
>> >>>> >> data sets with different period type) when creating and updating
>> >>>> >> new
>> >>>> >> data
>> >>>> >> sets.
>> >>>> >>
>> >>>> >> To unsubscribe from this bug, go to:
>> >>>> >> https://bugs.launchpad.net/dhis2/+bug/589776/+subscribe
>> >>>> >>
>> >>>> >
>> >>>> > --
>> >>>> > Data element period not enforced with data set
>> >>>> > https://bugs.launchpad.net/bugs/589776
>> >>>> > You received this bug notification because you are a member of DHIS
>> >>>> > 2
>> >>>> > developers, which is subscribed to DHIS.
>> >>>> >
>> >>>> > Status in DHIS 2 - District Health Information Software: Confirmed
>> >>>> >
>> >>>> > Bug description:
>> >>>> > It is possible to add a data element to a data set even if the data
>> >>>> > element is a member of another data set with a different period
>> >>>> > type than
>> >>>> > this one. This should not be allowed.
>> >>>> >
>> >>>> > We should filter out data elements with a different period type
>> >>>> > (member
>> >>>> > of data sets with different period type) when creating and updating
>> >>>> > new data
>> >>>> > sets.
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > _______________________________________________
>> >>>> > 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
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> --
>> >> 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
>
>