dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

Hi Calle,

But I thought you said you were importing this data from 1.4? My point
was, if you are importing this from 1.4, you could simply transform
the data into something which appears to be daily. If people were to
enter both, well, of course that would be a problem, but if it is a
centralized data transformation from 1.4 and importing it into DHIS 2,
then it should not be an issue, as this situation could be easily
checked for.

You are certainly right about the catcombos being able to be used for
just about anything, but usually when it does not feel right, it
probably isn't. Representing days with categories would seem just as
risky and you would of course loose all of the ability to aggregate
things over time (days to months, months to quarters etc).

In regards to the documentation (or lack there of), it is really up to
the community to document what is good and bad practice. Contributions
are welcome and needed. (https://github.com/dhis2/dhis2docs)

Regards,
Jason




On Tue, Feb 3, 2015 at 10:53 AM, Calle Hedberg <calle.hedberg@xxxxxxxxx> wrote:
> Than/Jason,
>
> You cannot compare this with e.g. using departments of hospitals as
> categories (to me an obviously BAD idea since you are trying to model
> what is fundamentally an geographical/administrative dimension
> phenomena as a fact dimension phenomena).
>
> For me, using a daily data set with some data elements captured daily
> and some data elements captured "monthly" is equally prone to become a
> mess - you actually need very stringent controls ensuring that users
> do not end up capturing both. In the type of changing environment we
> have - where facilities are gradually shifting from using monthly
> capturing at facility level to using daily capturing at
> service/consulting-room/ward level - it will be very very difficult to
> manage.
>
> It is also important to understand that the use of daily capturing is
> a data collection side phenomena/artefact - nobody is going to use the
> daily values for anything beyond the initial data completeness &
> quality assurance cycle. So after a year or two, we might simply do a
> backup of those daily values and then remove them from the production
> system, leaving only the monthly totals that are used for analysis and
> reporting.
>
> Otherwise, your point about the hosp dept highlights a fundamental
> weakness with the current category/option design: technically the
> design enables users to do almost anything - when you combine that
> with limited or non-existing guidance (ref user manuals etc) on how to
> define them in a systematic manner, you get a free-for-all landscape
> where many database instance ends up having chaotic dataset by dataset
> category/option setups that are difficult to maintain for the creators
> and nearly impossible to understand for other people joining later.
> (ref also a recent thread with posts by Bob, Jim, Jason, and the
> OpenMRS crowd)
>
> Regards
> Calle
>
>
>
> On 03/02/2015, Ngoc Thanh Nguyen <thanh.hispvietnam@xxxxxxxxx> wrote:
>> Hi Calle
>>
>> I voted for Jason's suggestion. In Vietnam, in many cases we use this
>> approach.
>> Hacking dhis2 by using days as categories will be problematic in the long
>> run although such problems may not be visible now.
>>
>> Once time in the past someone told us to use departments of hospitals as
>> categories (instead of orgunit). We followed this and this went bankcrupt
>> shortly.
>>
>> Thanh
>>
>> On Fri, Jan 30, 2015 at 9:52 PM, Jason Pickering <
>> jason.p.pickering@xxxxxxxxx> wrote:
>>
>>> Why not just make the dataset daily and transform all monthly data such
>>> that it occurs on the last day of the month?
>>>
>>> On Fri, Jan 30, 2015 at 2:11 PM, Calle Hedberg <calle.hedberg@xxxxxxxxx>
>>> wrote:
>>> > Hi,
>>> >
>>> > I need some urgent feedback on one very specific issue:
>>> >
>>> > 1.
>>> > We have a lot of monthly data that have been captured on a daily basis
>>> > (up to now in 1.4). The data is in reality monthly aggregated data
>>> > because it is the monthly totals that are used for indicators,
>>> > analysis, reports etc - but the data is captured daily into DHIS to
>>> > enable consistency/completeness tracking and to cut down on the
>>> > erroneous manual data compilation from paper forms at the end of every
>>> > month.
>>> >
>>> > 2.
>>> > Initially, the HISP team converted these daily captured values in 1.4
>>> > into datavalues in DHIS2 with dataperiodtype = daily. This approach
>>> > has various shortcomings, in particular when the use of daily
>>> > capturing is slowly being rolled out - meaning that while let us say
>>> > 30% of all facilities captured data on a daily basis themselves, the
>>> > remaining 70% are still submitting monthly summary forms to the
>>> > sub-district office for capturing as monthly total data.
>>> >
>>> > 3.
>>> > I believe a more logical approach is to store the daily data (Day01,
>>> > Day02, ...., Day31) as categories - as mentioned, we are in general
>>> > NOT using those daily values for anything beyond the initial data
>>> > quality and completeness process.
>>> >
>>> > QUESTION:
>>> > 1. Are there any major drawbacks to storing these daily values as
>>> categories?
>>> >
>>> > 2. Are there any major limitations with regard to the design of data
>>> > entry forms that will make it difficult to have a "matrix" type data
>>> > entry form where
>>> > (a) the user select OrgUnit, DataSet, and the DATE (as in 2015-01-30)
>>> > (b) the year/month part of that date determines the dataperiodid
>>> > (c) the day portion of the date determines which category will be the
>>> > right-most column in the data entry matrix
>>> > (d) we can display let us say 7 preceding days in the matrix to assist
>>> > the data capturer with eyeballing data during capture (dynamic
>>> > selection & display of categories).
>>> >
>>> > So the entry form would show up as
>>> > DataElement Day23 Day24 Day25 Day26 Day27 Day28 Day29 Day30
>>> > <data element1> 17 14 15 22 18
>>> > 19 20 <entry>
>>> > <data element2> 13 11 19 8 15
>>> > 12 10 <entry>
>>> >
>>> > Any quick feedback would be appreciated
>>> >
>>> > Regards
>>> > Calle
>>> >
>>> > *******************************************
>>> >
>>> > Calle Hedberg
>>> >
>>> > 46D Alma Road, 7700 Rosebank, SOUTH AFRICA
>>> >
>>> > Tel/fax (home): +27-21-685-6472
>>> >
>>> > Cell: +27-82-853-5352
>>> >
>>> > Iridium SatPhone: +8816-315-19274
>>> >
>>> > Email: calle.hedberg@xxxxxxxxx
>>> >
>>> > Skype: calle_hedberg
>>> >
>>> > *******************************************
>>> >
>>> > _______________________________________________
>>> > 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:+46764147049
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>
>
> --
>
>
> *******************************************
>
> Calle Hedberg
>
> 46D Alma Road, 7700 Rosebank, SOUTH AFRICA
>
> Tel/fax (home): +27-21-685-6472
>
> Cell: +27-82-853-5352
>
> Iridium SatPhone: +8816-315-19274
>
> Email: calle.hedberg@xxxxxxxxx
>
> Skype: calle_hedberg
>
> *******************************************



-- 
Jason P. Pickering
email: jason.p.pickering@xxxxxxxxx
tel:+46764147049