dhis2-devs team mailing list archive

[Calle Hedberg <calle.hedberg@xxxxxxxxx>]

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

*******************************************