Consider examining "text" in race/ethnicity extensions

[mikix]

The race and ethnicity extensions offer several levels of detail: ombCategory codings (10,000 foot view), detailed codings (nitty gritty), and text string (:shrug:).

We currently only examine ombCategory and detailed codings (preferring ombCategory values). And only actually use the display values found there.

Should we also examine text.valueString? text is actually the only required field and we only use display values anyway. But... who knows what the data quality is like there.

A part of me doesn't even like looking at display values, instead preferring to stick to the ombCategory values, looking at the code/system, and providing the string ourselves. That way, we don't rely on any weird EHR presentations of the strings. But maybe that's too paranoid. (Note: I did get that paranoid though for the data-metrics study)

[dogversioning]

we talked about this off thread, and the preferred approach to this, and more generally for extensions that are well defined, is to create a column for each possible field - this allows for maximal downstream flexibility.

so in this case we would have race_ombSystem_code, race_ombStytem_display (and perhaps a race_ombSystem_version and race_ombSystem_userSelected) from the ValueCoding, a similar set for race_detailed_*, and a race_text from the ValueString.