dhis2-devs team mailing list archive

["Dapo Adejumo" <dapo_adejumo@xxxxxxxxx>]

Hi,

Very Interesting view points here and it tells a lot about how we approach
Country Health Information Systems. The idea that IPs can generate separate
values for the same dataelement for same orgunits negates the principles of
essential/minimum datasets. Weakening of Country HIS basically start from
this as "Nobody believes the MOH vaues". Of course there can be additional
reporting requirements outside of the essential datasets and which are often
time bound and IP/Program dependent.

One interesting thing that has happened in Nigeria is the Regionalization of
IPs(HIV/AIDs) which essentially means no 2 IPs will work in the same
facility/district at least on HIV/AIDS. In other words the system needs to
be structured first rather than put the burden on the technology . I know
this is simpler said than implemented .

On the other hand, from Greg's Initial concerns, Individual records in the
DHIS can be aggregated to existing aggregated data tables . if patient
records are going to be migrated via EMRs , I assume this will be done using
the patientdatavalue tables? And then this should be easily aggregated from
queries? The question will be which aggregated value to accept - from the
manual facility aggregates of patient level data.

 

 

................................................

 

Regards,

 

Dapo Adejumo

+2348033683677

skype : dapojorge

 

From: Dhis2-devs
[mailto:dhis2-devs-bounces+dapo_adejumo=yahoo.com@xxxxxxxxxxxxxxxxxxx] On
Behalf Of Jim Grace
Sent: 06 March 2014 23:29
To: Vincent Shaw
Cc: Farai Mutero; Jason Phillips; Greg Rowles; Ferdie Botha; DHIS 2
developers
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
<mailto: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 <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
<mailto: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 <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.htm
l#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
<mailto: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

 

-- 

  <http://hispsa.org/timesheets/images/HISP-logo.png> 

Business Intelligence Planner

Health Information Systems Programme

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Mobile  :    073 246 2992 <tel:073%20246%202992> 
Landline:   021 554 3130

Fax:          086 733 8432 

Skype:      gregory_rowles


_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
<mailto:dhis2-devs@xxxxxxxxxxxxxxxxxxx> 
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp