dhis2-devs team mailing list archive

[Kim-Anh Vo <catakim@xxxxxxxxx>]

a minor missing:


On Fri, May 21, 2010 at 11:09 AM, Kim-Anh Vo <catakim@xxxxxxxxx> wrote:

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

daels-period-ou (dataset: daels, period, then assign dataset to ous) >>>
daels-ou-period (dataset: daels, *ous*, then assign ous 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
>



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