dhis2-devs team mailing list archive

[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



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