← Back to team overview

dhis2-devs team mailing list archive

Re: Advocating for changes to Data (values) Model/Table in DHIS2

 

Hi Greg,

There's a new feature in DHIS2 2.14 that you might find useful, called
attribute categories. Previously we used categories only for
disaggregation, but now we allow them to be used as additional,
user-defined "dimensions" of the data. And they're assignable at the data
set level, not by individual data elements. I totally agree that it's best
not to burden the OU hierarchy with things that are not properly OUs.

Please give this a look and see if it could help you -- and give us
feedback either way.

http://www.dhis2.org/doc/snapshot/en/user/html/dhis2_user_manual_en_full.html#d5e723

For the future we are also planning to provide ways of grouping these
attribute categories to add more structure to them.

Cheers,
Jim



On Thu, Mar 6, 2014 at 3:13 AM, Greg Rowles <greg.rowles@xxxxxxxxx> wrote:

> Hi Devs
>
> I'd like to advocate for changes to the DHIS2 data model - to cater for
> data-provider.
>
> In South Africa we are anticipating a complex environment filled with
> electronically generated (aggregate) data going into DHIS2 (e.g. from
> medical record systems). In one example in the Western Cape - data enters
> the DHIS2 from a patient record system (known as PREHMIS). Alongside this -
> data is also entered manually but all at the same facility. To accomplish
> this we had to configure a hierarchy structure that catered for:
>
> i) PREHMIS generated data (inserted electronically),
> ii) offline-PREHMIS data (entered manually),
> iii) community-outreach data (entered manually),
> iv) facilities without PREHMIS (entered manually, a combination of i and
> ii) and
> v) grand-totals at facility level
>
> We resolved to configure a complex list of OU6 repunits and it seems to be
> working so far. My question is - should we not be catering for
> data-providers as part of our data model? If we continue to solve
> complexity issues through the organisational hierarchy - we're setting
> ourselves up for an interesting data management situation. We will be left
> with a Cartesian-product of data-provider 'types' all stored inside the
> organisationunit table for each and every OU5. Is this something we can
> solve with a dataproviderID ?
>
> Right now in South Africa we're working on a data-dictionary and we plan
> to cater for data providers (or information systems). Our goal is to create
> a national Data-Dictionary that acts as a registry of information systems,
> (Master) facility and hierarchy information, (eventuall) a facility
> classification registry, and a registry of data elements and indicators. I
> believe this supplements the WHO/PEPFAR expectations of a MFL...
>
> I want us to plan forward for a universal data warehouse that caters for
> all types of aggregated-data whether they are submitted electronically
> or collected manually but solving this with the organisationHierarchy is
> going to be messy. Time to start planning our way through this guys...?
>
>
> Best,
> Greg
>
> --
>
> Business Intelligence Planner
> *Health Information Systems Programme*
> *- - - - - - - **- - - - - - - **- - - - - - - **- - - - - - - **- - - -
> - *
> Mobile  :    073 246 2992
> Landline:   021 554 3130
> Fax:          086 733 8432
>  Skype:      gregory_rowles
>
> _______________________________________________
> 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
>
>

References