dhis2-devs team mailing list archive

[Kim-Anh Vo <catakim@xxxxxxxxx>]

hello,

On Thu, May 20, 2010 at 4:21 PM, Ola Hodne Titlestad <olatitle@xxxxxxxxx>wrote:

> Hi Kim Anh,
>
> I am not sure I fully understand your problem.
> Maybe you could show us a few examples of data sets, data elements (English
> translations) and different period types to illustrate your problem?
> Thanks.
>
>
The issue here is quite clear because even the same daels (or even dataset)
but for diff ous they want to enter data with diff periods though the
expected-reports are with the same period to MoH, for example. That's for
their local follow-up-data-strategy.
For example for daels of Mother and Child Program, in HCMC they enter data
quarterly/monthly but in Cantho they do that monthly.

A finally/reluctantly possible solution maybe is assigning all conflict
datasets with monthly-type and then for entering quarter1/2/3/4, choosing
Mar/June/Sept/Dec. And needs explanation to users and more...

Note that saving values with different period types for the same data
> element will easily become messy and end in duplicate and overlapping data
> that the system will not mange well.
> So this constraint is important in keeping any DHIS database consistent and
> should not be violated. In fact there should be some validation of this in
> data entry and data import as well, and not just in the manually run
> integrity checks.
>
> In your case it sounds like you need multiple data elements with different
> period types. The use calculated data elements or indicators, or some custom
> aggregated reports to combine the data with different period types for data
> analysis.
>

so solutions for multiple-period-data vs. analysis and report are quite okay
BUT for multiple-period-data vs. data-entry is not yet?
Thinking of checking data integrity or entry for the case: daels-period-ou
(dataset: daels, period, then assign dataset to ous) >>>  daels-ou-period
(dataset: daels, ou, then assign ou to period-type)


> The best solution is the non-technical one, to enforce the same data
> collection frequency for all orgunits, and that way achieve a more
> consistent data warehouse. I understand that this might be difficult to
> achieve though.
>

yeap, political way is a better one here but it'd be a long way to go :)
because of local custom/culture/history


>
> Note that the reporting frequency (data export up the hierarchy or report
> generation) does not have to be the same as the data entry frequency. The
> important point is to make sure data is collected for the same period type
> across units at the lowest level.


> Ola
> ---------------
>
>
>
> On 20 May 2010 11:02, Kim-Anh Vo <catakim@xxxxxxxxx> wrote:
>
>> Hi all,
>>
>> The subject I have given out: "Dataset vs. import/export vs. dael-dataset
>> integrity checking" appears when I am working on building an
>> integrated-health database.
>>
>> The points for the above objects:
>> 1. Dataset (or discussed as dataelementSet): is a list of dataelements for
>> entry, import/export, etc.
>> 2. Import/Export datavalue (or maybe called dataelementValue) is based on
>> dataset, it means that dataelement value is only exported/imported by being
>> included in at least one dataset.
>> 3. Dataset-integrity checking to find the violate: *Data elements
>> assigned to data sets with different period types*
>>
>> See the above under a data warehouse (or just a central data repository)
>> situation: all daels, datavalues, etc. from local databases would be
>> imported into that sys.
>>
>> Back to the objects vs. DHIS2, there are some issues:
>>
>> *iss1)* Data (dataelementvalue) imported from many sources from diff
>> local places (nations, provinces, dis., etc.) SO a unified dataset with a
>> unified period for all is unlikely possible. As a result of this,"
>> dael-dataset integrity checking" criterion is hard to be fulfilled
>>
>> *iss2)* Data import/export all the time goes with datasets so everytime
>> importing/exporting datavalues, dataset is an attached element for the tasks
>> with the additionally important info: period, ou, etc. of the dataelements.
>> So, whether the repository (data warehouse) needs that local dataset or not
>> they (reluctantly-imported-dataset) do exist!
>> And of course, as a central data house/repository: import/export is a
>> basic function, so will we find another criterion for checking-out the
>> dael-dataset-integrity for a data warehouse/repository?
>>
>> Any ideas?
>>
>> --
>> --
>> Best regards,
>> Kim-Anh Vo
>>
>> +84.906612246
>> kavo@xxxxxxxxxx
>> Coordinator of HISP(hisp.info) in Vietnam
>> Master of Information Systems
>> at the University of Oslo
>> ------------------------------------
>> join facebook at www.facebook.com join LinkedIn at www.linkedin.com
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>


-- 
-- 
Best regards,
Kim-Anh Vo

+84.906612246
kavo@xxxxxxxxxx
Coordinator of HISP(hisp.info) in Vietnam
Master of Information Systems
at the University of Oslo
------------------------------------
join facebook at www.facebook.com join LinkedIn at www.linkedin.com