Does OMOP really only have 2 standard values for gender?
There are more, but you need to be specific, such as âtwo-spiritâ instead of âgenderâ. Check Athena, PPI vocabulary has all kinds of gender options that you can pick and they are all mapped with the OMOP standard IDs as âstandardâ.
Hmm, I guess Iâm a little confused here. I thought gender_id in the person table was supposed to be populated with only standard concepts (standard_concept=âSâ) in the gender domain (domain_id=âGenderâ) from the concept entity. If this is not correct, what are the acceptable (preferred) concepts that can be expected to be found in the gender_concept_id attribute of the person entity?
I wonât call it ânot correctâ. In my use case, âGenderâ is the domain. âMaleâ and âFemaleâ are only two of the over twenty options on my dropdown list (Canadians are crazy). My task is to map all my available options/choices with a standardized OMOP ID. It is up to my software engineers to decide what to do next.
Do you have a better solution?
The misunderstanding is in thinking that the gender_concept_id field in the person table contains the personâs gender. It does not. It contains âsex at birthâ:
This field is meant to capture the biological sex at birth of the Person. This field should not be used to study gender identity issues. (CDM 5.4)
Calling the domain âGenderâ is confusing, but there was a time when âgenderâ was used as a synonym for sex (Wikipedia article). In light of that, it is probably reasonable that it only contains male and female, although thereâs a deprecated, non-standard concept âambiguousâ that arguably should be standard.
The spec further says
If the source data captures gender identity it should be stored in the OBSERVATION table.
⌠at which point, as observed by @CHE, you have many more choices.
1 Like
The misunderstanding is in thinking that the gender_concept_id field in the person table contains the personâs gender. It does not. It contains âsex at birthâ
Although there is intersex [=hermaphroditism - the biological sex in which people are born with any of several sex characteristics including chromosome patterns, gonads, or genitals], that cannot also be mapped to Standard Gender, the OMOP CDM can be flexible as Rowlingâs Room of Requirement 
.
One possible recipe:
- Create separate source_vocabulary_id for all gender-related codes
- Map these codes to any appropriate Standard concept from the Observation domain (e.g. Gender Identity: Non Binary, Gender Identity: Transgender). Source codes, that will not get mapping, can become Standard by themselves)
- Populate the Observation table (target_concept_id => observation_concept_id).
1 Like
Great conversation everyone!
A couple of thoughts:
- Arenât there something like at least 6 common biological values for sex at birth (karyotype)?
- Thanks for the recipe for modeling gender identity @Polina_Talapova
Iâm thinking observation period might be employed here: an individuals gender identity can be noted as an observation during a visit and an open ended observation_period could be created to indicate that this is an observation that is somewhat enduring and does not need to be noted with each additional visit?
Thanks again!
observation_period is a table used to define when observations may be recorded for the personâŚnot a period of time that a person is observed in a particular state. This is a very important feature of the obseration_period table, and shouldnât be overridden to mean different things.
@jpallas said it. We even considered renaming gender_concept_id to sex_concept_id. The genders are all observations, and you can use any Observation Domain concepts with the full richness of those concepts.
âAmbiguousâ is a flavor of null. In OMOP, the concept_id for that is always 0. Just like âDonât knowâ, âPrefer not to to tellâ, âGive me a break and stop bothering meâ, âI donât know myselfâ. For analytical purposes, they are all the same (unless you do some linguistic or sociological studies, which are not our use cases).
1 Like
It appears there is an opportunity to improve On the CDM understanding of gender and help eliminate transphobia. It looks like the suggestion is to include numerous different options under under person identifier rather than making trans gender an observation. Limitation of person identifier to two genders implies that any gender different then male/female is not a normal option.
Transphobia, encoded: an examination of trans-specific terminology in SNOMED CT and ICD-10-CM
A Ram, Clair A Kronk, Jacob R Eleazer, Joseph L Goulet, Cynthia A Brandt, Karen H Wang
Journal of the American Medical Informatics Association, Volume 29, Issue 2, February 2022, Pages 404â410, https://doi.org/10.1093/jamia/ocab200
Published:
27 September 2021
1 Like
Hi @jkw321:
Welcome to the community. And to our debates here.
Observations are patient-specific, just like the gender_concept_id or any other field. There is no difference. @Polina_Talapova suggested to expand the concept space to describe all the genders. It will fix the problem.
But this is an Open Source community. The rule is: If you detect a need and the solution is not there - it is your job. There is nobody to blame with anything other than ourselves.
There is no reason to blame anyone for anything (karmic law). All of us are on the right track. Iâm sure that Gender representation in OMOP will become better if more people are interested in that.
4 Likes
The unfortunate thing is that âsex assigned at birthâ is very rare in source data. Our source data, for example, has âadministrativeâ or legal sex for over 99.9% of our patient population, and sex assigned at birth for less than 0.15%.
If we populated the PERSON table according to the specification, we would have almost all 0s in that column named gender_concept_id and containing sex at birth. Cohort stratification and analysis by gender/sex would be useless. Instead, we use the current-at-extract legal sex to populate gender_concept_id, which could have changed during the observation period and is likely to be inaccurate (that is, different from sex assigned at birth) for trans people.
All we can do is choose which flavor of wrong we are.
Epic appears to provide customers with the following codes for administrative sex out-of-the box:
We mapped the following SNOMED concepts to these local codes expecting to be able to pick up the appropriate omop concept id from a query of the vocabulary files. However, it doesnât look like these concepts have been mapped to a standard concept.
I was expecting to see a mapping from | Feminine gender (finding) | to OMOP standard concept_id 8532 and from | Masculine gender (finding) | to OMOP standard concept_id 8607.
@Christian_Reich, am I missing something?
Thanks in advance for any insight,
piper
Hello @piper,
When you map source values which lack a code supported by the OHDSI vocabularies, you need to map them to standard concept_ids. The CDM conventions tell you how to find accepted codes for your data. The codes you chose are not standard concept_ids.
In Colorado we chose to do a coalesce of sex assigned at birth and sex. If sex assigned at birth is NULL, then the ETL pulls in the sex value. This has decreased the percentage of unmapped source values (Unknown, X, Nonbinary, etc.) which were coming from the sex field.
This is probably because OMOP standard gender_concept_id, e.g., 8532 and 8507, refers to biological sex at birth. If the source data captures gender identity it should be stored in the OBSERVATION table.
Hi @MPhilofsky,
Thanks so much for the response.
Quick question about this:
When you map source values which lack a code supported by the OHDSI vocabularies, you need to map them to standard concept_ids
Weâve created a view of the mapping from non-standard concept_id to corresponding standard_id using the CONCEPT_RELATIONSHIP and CONCEPT tables. The query of course returns no OMOP standard concept_id for any of the SNOMED gender identity concepts.
Would it be possible for OMOP to create a mapping to standard concept_id for gender identity (which I agree is different than either legal sex or sex assigned at birth)? This would allow for an OMOP standard concept_id for the OBSERVATION table.
Thanks!
Piper
You are welcome, @piper!
@Alexdavv and friends are in charge of the OMOP vocabularies. Iâll let him answer the question.
1 Like
Quick question on this:
In Colorado we chose to do a coalesce of sex assigned at birth and sex. If sex assigned at birth is NULL, then the ETL pulls in the sex value.
When you say sex, are you referring to legal sex?
Not sure which EHR youâre using, but it looks like Vanilla Epic provides the following fields to capture sex and gender concepts:
it sounds like your approach is to extract the first non-NullFlavor value from sex assigned at birth, then legal sex, and use that for GENDER in the PERSON table.
Would you recommend adding records to OBSERVATION to capture each of the following?:
Legal Sex
Gender Identity
Sex Assigned at Birth
Iâm leaning toward modifying our approach to use your method of assinging GENDER, but am thinking that adding the additional detail to OBSERVATION would allow reseachers to select which flavor of sex / gender (or combinations thereof) to use for different analyses.
What are your thoughts?
Piper