dhis2-devs team mailing list archive

[Jim Grace <jimgrace@xxxxxxxxx>]

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@xxxxxxxxx> 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@xxxxxxxxx]
> *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@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
>
>
>
>
>