The Capacity Project has published a new technical brief on data quality: Data Quality Considerations in Human Resource Information Systems Strengthening. The brief was written by Samwel Wakibi, our HRIS advisor for Kenya, Uganda and Southern Sudan and our expert on data quality.
Data quality issues have been central to the program experience of the Capacity Project. Experience with issues of data quality has particularly been gained within the Project’s focus on strengthening human resources information systems (HRIS) to support health workforce planning and management. This brief discusses concepts of data quality and provide examples of the importance of data management specific to the field of HRH, illustrated by the Capacity Project’s experience with HRIS strengthening in developing countries.
Read the full brief: http://www.capacityproject.org/images/stories/files/techbrief_10.pdf (PDF).
Posted by
Shannon Turlington on 8/25/2008 • Tags: Data Quality, Data management, HRIS, Information Systems, Publications, iHRIS
No Comments Yet
Add Yours
Well, the best answer is “not much.” As I work on an HRIS implementation in Kigali, Rwanda, this week, I have been giving the need for accurate, continuously maintained data a lot of thought. Many developing countries have embraced decentralization—the shift of decision-making authority from the central level to the regional or local level. While decentralization has many good points, it presents challenges for collecting country-wide data. Imagine a situation where every region and district used a different method for collecting and sharing data on health workers! While separate methods of data collection might work well locally, lack of consistency across the country makes collection of data for use at the government level challenging at best.
We all know databases rely on consistency of information to generate reports. To get consistent data, regional and local health managers must have a way of submitting standardized data to the central level that does not add an excessive additional burden. More importantly, local health leaders must see the benefit of providing data to the central government—access to country-wide aggregate information, increased services from the Ministry of Health or easier maintenance of their own health worker records.
Ensuring a local level commitment to share data is only half the challenge. Western culture is data oriented—we love charts, graphs and numbers. Because current data is often lacking, many health leaders in developing countries have, by necessity, learned to rely on intuitive decision making. Add this to an increasingly rapid shift from paper based systems to databases and the process can be overwhelming.
For me, this is where Pam McQuide’s stakeholder leadership group model becomes so important. Stakeholders united in a common purpose and pursuing a shared benefit can agree on appropriate, effective ways to evolve well-entrenched methods of data collection. Having seen the success of the stakeholder model time and time again, even I find myself here in Rwanda still fighting the siren song of the perfect system to focus on what is most important— local stakeholder leadership and the data itself.
Posted by
Vanessa Spann on 10/24/2007 • Tags: Data Collection, Data Quality, Decision-Making, ICT4d, Information Systems, Leadership
No Comments Yet
Add Yours
When we design information systems, particularly working with stakeholders who have had difficulties accessing data in the past, it can be very tempting to collect every piece of data we can think of, just because we now have a tool that can capture and store the data. But we have to resist such temptations, or we’ll end up with systems that are too bloated to maintain and unwieldy amounts of data that are impossible to analyze meaningfully.
We’ve all seen forms that ask for so much information it’s exhausting to even think about filling them out. What incentives do we have to complete such forms, or to not rush through them as quickly as possible? The data entry person who fires up a bloated information system has the exact same reaction. When faced with a seemingly endless number of fields to complete, she might be tempted to skip some or fake data if all fields are required. She typically doesn’t know what is critical to the analyst. So bad data goes in, and bad analysis comes out. The system runs the risk of being abandoned, either by the people trying to maintain it or the people trying to get information out of it — or by everyone.
It’s better, when first designing the system, to ask “why” about each data field that is proposed. Why is it necessary to collect this? What report will require that data item to be complete? How will you use this piece of data to make better decisions? That’s why we typically ask stakeholders to come up with their most critical policy and management questions that they have been unable to answer because they couldn’t access the pertinent data. This process narrows the types of data that the system needs to collect to only the most critical pieces of information and helps us avoid “data smog” that can actually keep analysts from making good data-driven decisions.
Even with this process, it’s difficult to control the kid-in-a-candy-store mentality. Sitting down with stakeholders and brainstorming requirements for a new module often results in calls for everything but the kitchen sink. Just because we can collect a lot of data doesn’t mean we should.
I think it’s better to take a minimalist approach, especially when first introducing an information system to an organization that hasn’t used one before. Real-world use of the system will reveal which critical pieces of data may still be missing, and those fields can be added in a later version, or by the organization with a customized need. It is better, I think, to risk the system being too small than being too large.
What do you think? How much data is too much?
Posted by
Shannon Turlington on 10/22/2007 • Tags: Data Quality, Decision-Making, Design, Information Systems
3 Comments
Add Yours
I had the great fortune to go hear Edward Tufte talk the other day. If you are unfamiliar, Tufte is a Yale professor who is a master at analytical design. He’s written (and self-published) four books on better information display and has even pioneered some new ideas in the field. Though there was a lot to learn in a one day course I will need to think and study much of it some more to start applying those ideas to our work here at IntraHealth. The obvious areas for Tufte’s lessons to work their way in are: interface design in our applications, reporting tools for iHRIS and other apps, our work on data-driven decision making, and the simple presentations we all have to make from time to time.
On presentations, Tufte has always had a lot to say (in the negative) about PowerPoint, and though sometimes humorous he did make it clear that often the bad design that PowerPoint forces on users is used in the dissemination (or more likely not) of very important, and life-saving information. Those are definitely not the times to not be using slow revealed bullet points!
One thing Tufte talked about that I personally want to think about more is the idea that the principle of design is the same as analytical thinking. One must show comparison and causality in design just as they would when simply thinking about the problem. A good chart is one that compares findings with a norm, or another similar scenario and then gives the cause. Yes, all in one chart. Tufte’s books are full of good examples from Galileo to a good newspaper sports page. When considering the amount of information millions of people acquire from the tables of the sports page everyday, it is not so daunting a task to show a similar amount of data to someone who needs to make a decision about the health care in their country. There is no such thing as clutter, there is only bad design.
We, at IntraHealth, are designing all the time. From software applications such as iHRIS, to paper-based public health systems, its all design. As Clay Shirky recently wrote “users are experts in their own lives” therefore “Design is humility.” Something we should always keep in mind.
Posted by
David Mason on 10/19/2007 • Tags: Data Quality, Decision-Making, Design, Development, Documentation
No Comments Yet
Add Yours
