Re-calibrating race and ethnicity

In an earlier post, I rambled on some about demographic, political and practical issues affecting an organization’s approach to capturing racial and ethnic data with Pika. Internally at LSNC, we have been actively vetting this issue in an effort to move toward an implementation that works effectively throughout our program, which includes a dozen or so geographic locations spread over the upper third of California, the single largest contiguous legal services program in the state.

Since writing that post, some of the issues seem clearer, if not dispositive, at least as they relate to how the U.S. Census deals with them:

  • Hispanic = Latino

This may seem obvious to some but a source of dissonance for others. Perhaps the reader doesn’t live in California or elsewhere in the Southwest, where the two terms in a given cultural or political context are not synonymous. (I’m also reminded of the comedian George Lopez’s famous line about how he’s uncomfortable with the term “Hispanic” because he finds it hard to get behind a label that has the word “panic” in it.) But the Census Bureau — albeit not without controversy — conflates the two terms to mean the same thing.

  • Hispanic = Any Race

The Census Bureau has attempted to establish a line of demarcation between its defined set of six basic racial categories (within which there are expansive lists of “ethnic” group subsets, e.g., the Asian “race” is inclusive of “ethnic” subsets of Chinese, Japanese, Thai, etc.) and a very broadly defined, all but global “ethnic” dichotomy targeted at identifying those of Hispanic origin. The Census Bureau is unequivocal that Hispanic or Latinos may be of any race.

  • Hispanic = We are the World

Even accepting the Census classification of “Hispanic or Latino,” membership in that global ethnic group does not mean just those of Mexican, Puerto Rican or Cuban origin but is also inclusive of some 30 ethnic subgroups (Salvadoran, Nicaraguan, Argentinean, etc.).

  • Census categories and federal funding

Standing outside the reasons or other rationales for the racial and ethnic classifications defined and relied upon by the Census Bureau, there is a statistical (and political) juggernaut that drives this discussion, and I quote:

The standards governing race and ethnicity were stated in Standards for the Classification of Federal Data on Race and Ethnicity issued by the Office of Management and Budget (OMB) in October 1997. All federal agencies, including the Census Bureau, who collect and report data on race and ethnicity must follow these standards.

End of story?

I don’t think so. But at least as additional information helpful in formulating a starting point for resolving our data capture dilemma, these additional details suggest several practical approaches. As alluded to in the earlier post, we are approaching an implementation that conforms to the Census classifications for a variety of reasons already stated there. Doing so suggests several implementation approaches, including:

  • By self-identifying, clients control classification by “race.”
  • The client should be prompted to self-identify as “one or more” racial classification within the Census racial categories. (How best to formulate that question or prompt is a separate consideration.)
  • Where the client identifies with any of the Census Bureau subcategories within its definition of “Hispanic” or “Latino,” the client should be recorded as “Hispanic.” Further prompting is not required, since the client’s racial self-identification fits the Census classification for “Hispanic,” which is the statistical point of that aspect of the data collection.
  • Where the client intially identifies with one or more racial or ethnic classification not within one of the Census-defined Hispanic subgroups (e.g., “Black,” “Hmong,” etc.), then the client should be prompted to resolve whether he or she would identify as either “Hispanic” or “Non-Hispanic.” (This is a totally “either/or” choice; there is not a third option for “neither.”)
  • Since the Census classifications are compulsory on all federal agencies, they should dictate basic boundaries for collection of client race and ethnicity data. Stated another way, federal funding sources are generally not free to reclassify population data in a way inconsistent with the Census Bureau classifications.
  • Non-federal funding sources should be willing to conform their demands for data collection of these same categories in a manner that is consistent with the federal standards. (Dream on?)
  • Organizations need to negotiate with their funding sources to determine the level of racial subcategory detail required. For example, will the funding source require tracking of target populations broadly by racial category (e.g., “Asian”) or more specifically by subgroup (e.g., “Chinese, Japanese, Thai, etc.”). Similarly, what level of detail will the funding source require in capturing data about the Hispanic/Latino population? Is that general category enough, or are you required to capture detail of the client’s membership in one or more of the 30 Hispanic subgroups?

OK. End of story now?

Not really. The real world is that large legal services programs have often scores of funding sources, with differing data demands. Even assuming your organization can amicably resolve with differing funding sources to defer to the Census classifications, some may want or demand differing levels of detail. Or the organization itself may want that level of detail, regardless. Or not. Within our own organization, for example, we are already hearing grumbling from one of our hotline services about its own institutional need to handle telephone “volume,” and how it will not be able to process intakes as “efficiently” should it be required to train and manage its staff and volunteers on the “intricacies” of racial and ethnic classifications and subclassifications.

Yes, we’re forty years into the legal services social justice movement and client delivery models and outcomes continue to drift toward data points of collection and bragging rights about numbers. Welcome to “equal access,” people.

But I digress.

We are trying varied approaches to how this would be implemented at the Pika Contact Information screen. (The usability convention is that check boxes imply one or more options, and radio buttons imply a single or either/or option.) The Contact Information screen seems the the logical location for racial and ethnic information related to the client.

Should we go with an approach that requires culling more specific information about the subsets within racial categories, it seems to me we should seriously consider a dynamic presentation of choices to the user. By that I mean that the flow of intake should branch the user to the required options, not all options. As a simple example, if a client self-identifies as “Chinese,” the user would select the “Asian” category, which would then trigger display of the Asian subset options, including the option for “Chinese.” If the client self-identifies with more than one basic racial ethnic category, then a dynamic display would be presented in turn for each basic racial category selected.

Depending on the number of subsets to be dynamically displayed, usability may dictate a simple set of vertical radio buttons where the subset is few in number, or a drop-down select field where the subset is larger. I think the very worst implementation would be if the screen were to display statically all the Census racial subcategories, regardless whether in a fully displayed laundry list or as a global drop-down select field.