Tragedies of the Human Service Data Commons

A lot of the human service sector’s problems with information look like tragedies of the commons.

Wikipedia’s definition: depletion of a shared resource by individuals, acting independently and rationally according to each one’s self-interest despite their understanding that depleting the common resource is contrary to the group’s long-term best interests.

Economists invented this notion for thinking about things like overfishing and air pollution. It’s an agricultural metaphor. Medieval estates had tracts of land that people could use together. They could graze their sheep in a common pasture. But if people tried to graze too many animals, the pasture would be ruined.

As an analogy for human service data, I’m going to try a different image: a common orchard. Anyone may take its fruit, subject to certain limitations. Anyone may plant a new tree, if they’re able. But in this community, people are very particular in their tastes. A lot of people plant exotic species that the others don’t enjoy. It’s a common orchard without common agreement on what to grow. So there are too many trees, and they deplete the soil. The trees become weak and the quality of the fruit declines. The branches tangle and choke each other. It turns into an unmanageable thicket. After a while people can barely get in to pick the fruit at all.

Where’s the analogy? In a human service organization, there are a lot of diverse demands for information. (That’s the fruit.) Some of them support operational processes such as intake screening or discharge planning. Some are for analytic purposes—performance measurement, quality improvement, evaluation. So all the stakeholders put different data collection requirements in place. (Those are the trees.) And then, as the various requirements rub up against each other, the problems start.

The definition claimed that people create tragedies of the commons despite their understanding that depleting the common resource is contrary to the group’s long-term best interests. Maybe so. But that awareness might be vague or subliminal. On a medieval estate, people knew there was a commons. (They called it a commons!) In the human service sector, people don’t talk about data that way. Data acts like a commons but is rarely recognized as one.

It should be. After all, human service data are a resource that is expensive to everyone. Some costs are explicit, others are hidden or intangible. There’s the cost of procuring and maintaining the mechanisms: software is expensive and so are standardized instruments. There’s the cost of staff. Yes, collecting data is part of their job; but if data collection isn’t efficient then it adds the cost of the missed opportunity to do something more worthwhile. That can be a bad hit to morale. And there’s the cost to clients. Data collection takes time. Too much can alienate the people that a program is trying to serve. So the costs are not only financial, they’re social as well.

In this blog’s first post, I outlined what I think are the human service sector’s four biggest information management problems. Several of them can be interpreted as tragedies of the data commons:

• Unsuccessful information system projects. The scramble of multiple stakeholders’ contradictory and fast-changing requirements drives up costs and increases risks.
• Barriers to producing performance measures. Entrenched data collection requirements occupy the resources that would be necessary to develop new ones.
• Uncoordinated demands on service providers. Separate requirements are a burden to grantees that have multiple funding streams.

(The other one, isolated agency silos, isn’t a tragedy of the commons—it’s the lack of a commons!)

So what can be done about it?

One approach that has gotten a lot of press is to try to standardize data requirements. (This is like saying: instead of everyone planting their own exotic varieties, we’re all going to agree that we’ll share fewer trees. Perhaps we can develop new breeds of trees that can satisfy more people.) Sector-wide standards could make it easier to communicate within, between and about different organizations. They could reduce the cost of having every organization pursue its own idiosyncratic choices. There are efforts to standardize at various levels; the most prominent are standardized performance measures and standardized elements for data exchange. Those efforts promote coherence and efficiency. They’re arguably the most important technical trend in human service information today. But standardization will not solve all our problems.

To build healthier human service data commons, I’m going to suggest three questions that the sector needs to take a closer look at:

1. How intentionally do organizations plan for the costs of managing data? Of course organizations make budgets for software acquisition and personnel. But in the ongoing stream of major and minor decisions that need to be made about data, how carefully are the costs—to all stakeholders—calculated? If the answer is not very well then what are the factors that make this hard to do?

2. How well do different constituencies communicate with each other about data? Who’s at the table? Can they enter into each other’s world-views? There ought to be a joke that would start:  So a caseworker, a program director and an evaluator walk into a software company… (I don’t know what the punch line would be.)

3. What is a human service information system anyway? People usually emphasize functionality, what the software can do. They talk about tools. Of course, an information system is—in one sense—a set of tools. If it weren’t then no one would use it. But there are more holistic ways of thinking about what an information system is—and they could be helpful for designing software that better serves the commons.

In future posts I’ll take a stab at these questions. In the meantime, if you have comments, experiences or resources, please share Your Thoughts below.

—Derek Coursen

If you found this post useful, please pass it on! (And subscribe to the blog, if you haven’t already.)

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License

---