Race and client self-identification

I would be interested to hear from other Pika users about how their organizations deal with “race” and/or “ethnicity” categories. It seems essential that an organization have a standardized, well formulated question format to elicit this information, but it is not so easy to resolve how best to proceed. One concern I’ve long had on this issue is the inconsistent categorizations of race/ethnicity demanded by varied funding sources, even among federal agency funders. It is very problematic from a centralized-database perspective if the categories aren’t consistent or don’t quite mean the same thing. If they don’t, the data becomes statistically suspect or outright worthless. This is something, albeit not everything, about the argument for purposefully adopting the current U.S. Census “racial” and “ethnic” categories, and addressing varied funders’ needs from that starting point.

A little background:

In the default Pika settings, this information is listed on the Contact Info page as “Ethnicity,” with a breakout into seven general, commonly used categories:

• White
• Black
• Native American
• Asian / Pacific Islander
• Multi-racial
• Other

Needless to say, these commonly used “racial” and/or “ethnic” categorizations now differ significantly from those used by the U.S. Census, the latter being fraught with criticism and concerns.

At LSNC we are approaching this issue with consideration of certain practical and political realities, among them:

• Funding sources that want this information tracked often diverge in how they categorize target populations along these lines, but in general the prevailing Census categories are all but universally acceptable to funding sources, and especially federal funding sources;
• If one wants to make effective use of Census demographic data in conjunction with analysis of client data, then one needs to track data in a way consistent with the Census categories (for example, if you want to do comparative GIS maps of your client data against Census data, then you need to map apples to apples, not apples to oranges); and
• At the end of the day, the U.S. Census is the 800-pound gorilla on this issue.

One way to implement this in Pika may be to do the following:

Using a series of check boxes, ask the client to self-identify and, based on that response, select one or more of the six “basic” racial categories:

• American Indian or Alaska Native
• Asian (inclusive of specified subcategories)
• Black or African American
• Native Hawaiian or Other Pacific Islander (inclusive of specified subcategories)
• White
• Other Race (e.g., self-identifies as ethnic-specific and/or not inclusive of the other five categories)

Using a second either/or radio button option, ask the client if s/he thinks of him/herself as Hispanic or non-Hispanic. (The answer would be one or the other, not both.)

The first set of choices are Census-defined “racial” categories. (The intake question should be presented in a way that the client understands that s/he may self-identify as a member of “one or more” racial categories.) There would be a help button to pop-up a window explaining what the categories mean. Users obviously would need to be trained to assure they understand these basic categories. The intake worker would check as many boxes as apply, depending on how the client self-identifies.

The second set of choices are Census-defined “ethnic” categories that are either/or. To be sure, this second cluster always risks confusion, since the client has already been asked about his/her “race.” But it differs in a key way that relates to highly useful Census data for tracking and analyzing the self-identifying “Hispanic” community. (The Anglo term “Hispanic” is itself viewed as problematic).

It seems it would be critical to rely on self-identification for the “racial” categories. Like questions about client primary languages, we would let the client identify the language; we would not suggest to them what it is. In contrast, it seems the second “ethnic” category of Hispanic/non-Hispanic would justify prompting.

Of course, the client should be given an opportunity to self-identify him/herself as one or more “racial” categories. But it seems inherently problematic if we are somehow “dissatisfied” because the client on his or her own fails to identify more than one. If staff begin to routinely prompt a choice or choices that the client would not or do not self-select, than the data collected is, arguably, flawed. And the big problem here is when a funding source creates incentives or a dynamic such that it prompts the grantee program to promote a response that fits the demands of the grant, rather than suiting the client’s self-identity with a racial or ethnic group, if at all. Put another way, are we prompting the client to state the one or more categories they view themselves as members of, or are we prompting the client to acknowledge membership in groups we perceive they are members of, or we need to justify a funding source?

That is one reason to carefully parse out the race question from the Hispanic/non-Hispanic question. The former warrants a different prompt than the latter; the first relies — better said, defers — to the client’s self-identification 100%; the second does not — it relies on a specific “ethnic” pigeon hole that we are asking the client whether s/he fits. It may be this is more important for us to know than the client to identify with.