dhis2-devs team mailing list archive

[Jim Grace <jimgrace@xxxxxxxxx>]

Hi Vincent,

Exactly right. One way to handle the duplicate data from two implementing
partners at the same facility is as follows: create a dummy implementing
partner that will "deduplicate" the data. Assign negative numbers to this
dummy IP that will cancel out the duplicate reporting. Then each partner
will get full credit for the numbers they report, but the numbers when
summed across all partners (including the "dummy") will not double count.
You could schedule some automated process to look for duplication between
partners and adjust the dummy values accordingly.

We're also looking at ways to restrict user accounts by category option
values -- so for example you could have user accounts who can enter values
only for a particular implementing partner. Stay tuned!

Cheers,
Jim



On Thu, Mar 6, 2014 at 10:29 AM, Vincent Shaw <vpshaw@xxxxxxxxx> wrote:

> Hi Jim
>
> Thanks for this response - I think this will help us. It's a smart
> addition to the functionality.
>
> As I understand this functionality, we need to understand who is
> collecting what data, because it does allow for double counting (if say two
> Implementing Partners (IP) capturing the same data at the facility level
> because they each want to report their values to the funder) - so one may
> not always want to add up the values across the different sources of data.
> In Greg's case, where I assume there would not be double counting, one
> could add across the sources to get the whole picture. Is that correct?
>
>
>
> Best regards, and thanks
>
> Vincent
>
>
>
> *From:* Jim Grace [mailto:jimgrace@xxxxxxxxx]
> *Sent:* 06 March 2014 15:44 PM
> *To:* Greg Rowles
> *Cc:* DHIS 2 developers; Farai Mutero; Vincent Shaw; Ferdie Botha; Jason
> Phillips
> *Subject:* Re: [Dhis2-devs] 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
>
>
>