dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Hi Calle

2009/3/14 Calle Hedberg <chedberg@xxxxxxxxxxxx>:
> Hi,
>
>
>
> I would strongly support this – it’s been part of the 1.4 data model from
> the start, and I think it was a mistake to weaken this in the 2.0 data model
> (I’m saying “weaken” because this type of constraint should be regarded as a
> form of “strong data typing”) due to lack of standardised data collection
> frequencies in Vietnam. As far as I can recall from previous discussions
> with Ola around this, the initial requirement decision in 2.0 to allow
> multiple data collection frequencies for single data elements was caused by
> the fact that there was no consistency between districts in Vietnam – some
> collected monthly data, some collected the data quarterly.
>
>
>
> In 1.4, we are regularly introducing new “layers” of user-defined
> constraints, in order to reduce the possibility of errors but also to
> enhance analysis and customisation. Two of the recent ones are the perceived
> need for DataElementAndIndicatorGroup SETS, and the need to fully support
> multiple Organisational Hierarchies with multiple OU level names etc.
>
>
>
> By the way, two other pieces of news that relates to what I’ve previously
> denoted as “DHIS 3” (the next generation DHIS which incorporates both 1.4
> modules and dhis 2):
>
>
>
> -          We recently got the source code (written in Delphi) to the HR
> Admin, a human resource database developed here in SA. It’s release was
> predicated on a Memorandum of Understanding between the developers and HISP.
> The developers have also designed a new more limited version of it for
> Nigeria (mostly using C# and .NET) that will be interfaced to DHIS 1.4 (and
> thus indirectly to DHIS 2).
>
> -          The new DHIS Referral Module – a hybrid of the CORE and PAT
> modules with specific functionality to capture and analyse patient referral
> data – will be ready for piloting in early April.
>
> -          The DHIS Client Satisfaction Survey module has finally been
> upgraded from 1.3 to 1.4.
>
> -          The use of DHIS 2 for the national South African data dictionary
> seem to be successful, even if there’s considerable work remaining to
> actually create and refine all the relevant dictionaries.
>
> -          The Debo ART patient module is more or less ready for piloting in
> the Eastern Cape province (this version of Debo is customised to handle the
> so called “adult clinical record” used in the eastern Cape).

Would love to get an update on what has happened with Debo
customisation.  Where can I get it?

Regards
Bob

>
>
> Regards
>
> Calle
>
>
>
>
>
> From: Lars Helge Øverland [mailto:larshelge@xxxxxxxxx]
> Sent: 13 March 2009 08:52 AM
> To: Dev list hisp.info; dhis2-devs@xxxxxxxxxxxxxxxxxxx; Pond, Bob; edem;
> John Lewis; Calle Hedberg
> Subject: DataElement -> PeriodType association
>
>
>
> Hi,
>
> I see the need for introducing an association between DataElement and
> PeriodType in the DHIS 2 data model. Currently you can look up the
> PeriodType of the DataSet of which the DataElement is a member, but this is
> not enforced as a DataElement can be a member of many DataSets. The need is
> based on a few new requirements:
>
> - Sierra Leone: Regression analysis where missing values are left out of the
> aggregated indicator value. In order to define a missing value for a data
> element, we need to know the PeriodType of the Periods to look for.
>
> - South Africa: Gap analysis. In order to define a gap, we need to know the
> PeriodType of the Periods to look for.
>
> - South Africa: Alignment of the DHIS 2 and DHIS 1.4 data model which is
> necessary for migration and data dictionary use.
>
> - India: Aggregated data export. We must know the PeriodType of the Periods
> that should be used to aggregate data for each DataElement in order to avoid
> duplication of data on higher levels.
>
> - General: Improved performance in datamart as you can reduce the number of
> crosstabulated Periods.
>
>
> The downside of this is that all current DHIS 2 databases must be updated by
> assigning a PeriodType to each DataElement. Also this will affect places
> where data is captured with different frequencies for the same DataElement
> (this might be considered a bad practise anyway).
>
> As an intermediate step we could disable this functionality for databases
> where DataElements registered for DataSets with different PeriodTypes exist.
>
>
> I would prefer introducing this association. Please comment on this.
>
>
> regards, Lars