dhis2-devs team mailing list archive

[Jim Grace <jimgrace@xxxxxxxxx>]

Hi Vincent,

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. :)

Cheers,
Jim


On Thu, Mar 6, 2014 at 6:31 PM, Vincent Shaw <vpshaw@xxxxxxxxx> 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@xxxxxxxxx]
> *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@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
>
>
>
>
>
>
>