Good discussion, thanks.
Please help me understand better the context in which you’re asking these questions. Are you assuming the government and IP systems are the same instance, or data is somehow being copied from one to the other? I’m not sure how to understand your statement “from the governmental perspective we should ignore the IP data…” Are you talking here about reporting to the government? Reporting to a donor like PEPFAR? From what system(s)?
I agree that everyone should be working towards convergence. Nobody wants different numbers. But until we get there I think we will continue to have some type of parallel reporting systems, where the government system has its own integrity and procedures, and donor reporting has its own integrity and procedures.
The way I see it, if a donor gives money to an IP to do some work, the donor is ultimately depending on the IP to tell the donor to the best of their ability how the money was spent. I think each IP needs to be given the ability to respond to this expectation in the best way they can. They need to be the ones to decide what data is right. In some districts/facilities maybe they are working well with the local government officials and can come up with the same data in a timeframe that meets both government and donor deadlines. In other facilities/districts maybe this harmonization isn’t yet working in practice, and the IP has to do the best they can to report. I think each IP has to figure out how to give their best numbers to their donor.
In Kenya, I’m accustomed to the government having their instance of DHIS2, and IPs collecting data separately for their donor. If you tell me more about how things work in your part of the world (or how you would like them to), maybe I can understand your questions better. 
···
On Thu, Mar 6, 2014 at 6:31 PM, Vincent Shaw vpshaw@gmail.com wrote:
Hi Jim
Yes, I agree that sometimes the timelines for IP may be different to that for the MoH. However, I do believe that we should all be working towards improving the timelines for government. Having said that, I see where this is going (in theory – the practice will be even more interesting!). It seems to me that it is still a pretty manual process to set-up the de-duplication function (duplications will need to be mapped facility by facility and district by district, and even so the patterns may change on a month by month basis…). So my thinking is this:
a) Where you are sure that there is no overlap between the IP (as in Greg’s case below) then one can add up all the values across the DS category combinations;
b) Where there is duplication, from the governmental perspective we should ignore the IP data, and utilise the public sector reporting as the “single point of truth”. If this is late in being entered, then one would utilise data from the IP as a proxy, taking into account that there may be double counting if it has not been de-duplicated…so where possible select data from the IP that has the largest coverage or widest range of support…
Would you agree with that?
Regards
V
From: Jim Grace [mailto:jimgrace@gmail.com]
Sent: 07 March 2014 00:29 AM
To: Vincent Shaw
Cc: Greg Rowles; DHIS 2 developers; Farai Mutero; Ferdie Botha; Jason Phillips
Subject: Re: [Dhis2-devs] Advocating for changes to Data (values) Model/Table in DHIS2
Hi Vincent,
I agree that in theory it would be best to use the MoH values. One challenge with this is timing. For example the deadlines to finalize data in the MoH DHIS2 instance in Kenya are later than the deadlines by which PEPFAR needs its data finalized for reporting to the US government. The other challenge is that a partner may not agree with the official MoH number. In the end, the funding organization such as PEPFAR needs to get the numbers that the implementing partner believes are right, whether or not they are the same numbers as the MoH system, or have (yet) been entered into the MoH system.
Having said that, of course all the numbers should be the same. What I’ve heard from PEPFAR is that if two partners report the same data element from the same facility for the same time period, the numbers should be equal. I’ve heard that partners should not pro-rate their numbers because of the amount or duration of support at a given site. If two partners give different numbers for the same data element, facility and period, this represents an error that needs to be reconciled so the two will report the same number. That’s the “official” story I’ve been told to assume.
If I assume all the numbers are the same, then the automatic “deduplication” could work: If (n) facilities report for the same item, and each reports the same value, you just subtract (n-1) times the value.
If this were (or is) not the case, then you could do manual “deduplication”. which is what I had assumed before I heard the above explanation. In manual deduplication, someone has to make a judgement as to what the total number should be “deduplicated” across partners. Then the manually-determined difference could be attributed to the dummy partner to make the aggregation work.
Cheers,
Jim
On Thu, Mar 6, 2014 at 4:48 PM, Vincent Shaw vpshaw@gmail.com wrote:
Hi Jim
What you suggest below is an interesting option. But I am struggling to understand how you would decide the value of the negative values in the dummy IP?
My thinking…… one source of data would be the MoH (say the Facility Information Officer (FIO)) and that they would capture the data which represents the “single point of truth” for that facility data. This is likely to be comprehensive across all the services? The data that IP use may then be the same values as the MoH data, or a % of those values (or even just other values captured on the basis of their own records), based on the type of support provided, and their level of effort. If you add the %’s across IP you may end up exceeding 100% (or exceeding the value entered by the MoH) since their services may overlap. The point is, even if you do create a Dummy IP that has negative values, how will you determine what the negative value is in the absence of some reference. If the MoH values are the reference, you may as well just use the MoH values?
Regards
V
From: Jim Grace [mailto:jimgrace@gmail.com]
Sent: 06 March 2014 17:44 PM
To: Vincent Shaw
Cc: Greg Rowles; DHIS 2 developers; Farai Mutero; Ferdie Botha; Jason Phillips
Subject: Re: [Dhis2-devs] Advocating for changes to Data (values) Model/Table in DHIS2
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@gmail.com 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@gmail.com]
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@gmail.com 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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp