This appears to me to be an ideological argument. How can we maintain standards of subjective truths? It seems to me that the “Observational” part of OMOP demands objective truths to be useful at all.
1 Like
This is absolutely not ideological. Genetic sex is what is needed for many analysis, as opposed to gender which may not match biological sex.
I would also note that anyone doing care of transgender patients needs to differentiate between genetic sex and gender.
1 Like
Well, if you only want to put it in the Observation table, why not create a Gender_Expression domain and store that as an observation? That way, the whole CDM doesn’t have to be modified with breaking changes that will affect everyone’s models, disrupt historic continuity, and every OMOP application from Atlas to Usagi.
It’s a lot of effort for very little lift.
The same thing was said around 10 years ago when I noted the issue. At the time, I was working on the Simons Foundation Autism Research Initiative (SFARI) and brought up the issue in this community. This is a fundamental modeling problem. Yes, it would need a migration to be planned, but, it can be done gradually, for several years ETLs can keep 2 fields synchronized without much effort.
If you think OHDSI is large now, just wait. It’ll be much larger in 5 more years. This problem will be much harder to address in the future.
But what observational research problem does it SOLVE that couldn’t be done by local expansion table/fields and local concept mappings?
It seems to me there should be more behind it than finding it offensive to use the word Gender for Sex .
Just linking
Github proposal, and another github proposal (previously mentioned here)
And I guess most of the discussions have been held here.
It’s not about things being offensive. It’s about being incorrect. Why should it be an error that a Male gendered patient has a papsmear? It’s not an error, in some clinics it’s a common phenomena. There are also drug studies that may be incorrect, or genetic analysis that should be excluding intrasex patients that don’t. It’s a health equity issue.
Don’t think of it as a burden, think of it as an opportunity. Surely there is health equity grant opportunities to make OHDSI more friendly towards those doing genetic analysis and care of patients whose gender is not the same as their biological sex. Such a grant could clean up more than just this problem and make OHDSI more welcoming and useful for a broader range of applications.
1 Like
I am already having the issue of changes happening faster than I can code around them. Remember, us small to medium sized institutions, we do not have the resources to chase every small change everyone wants. On top of that, there is already too much ‘judgement’ that has to be used in the ETL process; I wonder how useful much of the data in the CDM really is anyway.
1 Like
Friends:
We probably are not that terribly far away from each other:
- Gender is social, sex is biological at birth. Clark is right in that the current table name in the PERSON table is wrong. Roger is right that this wasn’t always so tightly defined. Certainly not when the OMOP CDM was initiated. Back then, you would use the terms synonymously, and you would avoid the word “sex” because of its connotation.
- From a use case perspective, everything is fine as it is: If you ignore the wrong name, what’s in the PERSON table (gender_concept_id) is the biological sex, and the real gender is in OBSERVATION. We can run any study we want including these two.
The solution is to rename gender_concept_id to sex_concept_id. Very simple. Problem is that this is a gigantic, breaking, non-backwards compatible change. I would say every single method, study package or software tool would have to be changed. So, that is definitely a major release. We could smoothen it by having both fields for a transition period. But that is also ugly.
So, the question is when do we want to do that? Roger says “when the cow comes home”, Cark says “asap, it is already embarrassing”.
3 Likes
It cannot be biological sex since doesn’t have an option for intrasex subjects. Instead, it’s closest to “gender at birth”, which is the most political inconsistent of all 3 options.
That’s a vocabulary problem and easy to fix. Plus it is a data problem: My hunch is that those cases are not well captured. Remember, for the vast majority of patients this gets entered by the front desk staff of an office or a registration office of a hospital. The gender information is probably more useful for those cases. And in international databases we may be even further away from the correct detail.
1 Like
…or from a data transferal from one EHR to another. Also, many patients demographics may be from old paper charts if the patient has been in the practice longer than the EHR has.
1 Like
Hmm. Perhaps the Gender column is named correctly with the best available data. Perhaps the problem is that we are trying to treat it as biological sex?
Perhaps we shouldn’t remove the Gender field from the Person table, but simply add the Sex column. If both fields are there, it means that those doing ETLs would not be able to ignore the differentiation, and could search for the best available data. Having both fields would mean those doing queries could also be more precise about what exactly they mean: gender or biological sex.
I believe the need for distinction is being recognized by publishers.
[Sex and Gender Analysis Policies of Peer-Reviewed Journals | Gendered Innovations]
1 Like
That’s one choice, but it probably doesn’t help us much:
- Sex is static. It is established at birth, and you get born only once. So, it should be in PERSON. The field we have (gender_concept_id) is actually used as if it were sex_concept_id. It just has the wrong name.
- Gender is dynamic. You can change it. Which means it cannot be in PERSON, but in OBSERVATION with a time stamp. All we need to do is to make sure we have a agreed gender concept convention.
The naming problem can be addressed as soon as we go to the next major version. There are other things we also want to change. If folks are eager - start rolling the drum.
In the mean time: We can add explanatory and apologetic language to the PERSON table documentation, explaining that gender_concept_id is wrongly named and really should be sex_concept_id, but otherwise it is all working.
Again, we don’t have a problem with the content. We have a problem with naming. Functionally, a variable or table field name is a memory address pointer for the processor. It means nothing. So, if we can live with having to apologize while we are working on a new version we are just fine.
1 Like
Thanks for this update. In fact, gender identity now has much clearer coding options and sex is still considered to be biological sex by journals, by the NIH, and others). I’d cast a vote for sex (adding intersex as a code) and gender, although gender could be an observation, as we code it now at our site. Gender identity can be fluid in a small number of people.
1 Like
As an ETL’er this is not always possible, as both fields may be in the demographics section, which does not have timestamps attached to them, at least not in the EHR that we use.
I see no way to change this that does not cause pain to someone, somewhere.
Thank you all so much for thinking about this. It’s not an easy topic.
I’m no expert, but I understand that most Intersex chromonal anomalies are discovered during puberty. Hence, this could be more dynamic than one might anticipate.
For transgender people receiving hormone replacement therapy, those detransitioning is extremely low. Hence, this is probably a bit more static than one might expect.
That’s good. However, adding another column wouldn’t be as disruptive.
If the goal would be to have one field rather than two, then this seems like a good first step. Even so, 90% of users don’t read manuals. So, perhaps a further step might be to change on screen field names and such, in the cases where it’s easy to do so. It’d create a discrepancy. That said, would let those building queries with graphical interfaces start using scientifically accepted terminology.
Being either Intersex or Transgender is about 2% of our population. Intrasex (those with chromosome anomalies) people are greater than 1% of the population. Those who are Transgender are also perhaps 1% of the population. For what it’s worth, I see these statistics as being somewhat like left-handed reporting, where it went from 4% (1920) to 12% (1960), leveling out and remaining around 12% since then. Only after it becomes socially acceptable to admit to these categories do we get accurate measurements.
Regardless, making the change will require funding. So, if we agree at the community level that it’s useful and state a direction to be more inclusive (being more useful to studies of these populations), then perhaps it would permit interested parties to write grants to cover development and data migration expenses. Those with relevant data sets may also be interested in collaborating further with OHDSI network studies.
Let me see if I understand this correctly. We are trying to accurately reflect both “sex” and “gender” in the CDM, with these considerations:
-
There are three categories of sex, a congenital characteristic assessed by the appearance of genitalia/reproductive organs: Female, Male, and Intersex.
-
A person identified at birth as “male” or “female” at birth might subsequently be reclassified as “intersex” based on clinical observations. No other transitions of “sex” exist, barring clerical or observational errors at delivery.
-
Gender, is a construct of perception of personal characteristics, both physical and non-physical which is influenced by genetic characteristics and social norms.
-
There are presently many gender terms in use, and it appears likely that the list will continue to grow/evolve.
-
At any time a person might identify with more than one gender or revise their characteristic.
If so, it seems that Gender needs to be a time-stamped record in the Observation table, hopefully standardized to a vocabulary curated by another entity.
Nor am I disagreeing with you, but do not make it mandatory or make it documented that the timestamp may be set to a magic number as our EHR does not have any history of demographics (other than audit trace and there is no way security is letting me use that to do OMOP work).