Stream: implementers
Topic: Birthsex on FamilyMemberHistory
Lloyd McKenzie (Oct 12 2018 at 14:45):
I'm concerned about the renaming of "gender" to "birthSex" on FamilyMemberHistory. I'm worried that it doesn't reflect what systems actually prompt for and what patient's necessarily report. I recognize that what's desired is typically the genetic gender of the family member in order to trace inheritance-related risks that are y-chromosome or x-chromosome-specific. However, if the patient will not always know the birthSex of a relative and if the data that existing systems have captured doesn't already reflect the birthSex of the relative, then the FHIR standard should align with existing practice - i.e. that the gender reflects reported gender which may or may not correlate with chromosomal gender. My preference would be to keep the name of the element as "gender" but to note a preference for capturing chromosomal gender; to note that "full" chromosomal gender (e.g. XYY) should be captured as an observation; that relationship type and gender won't necessarily correlate ("Aunt Sue" might be captured as male) and that reported gender and actual chromosomal gender may differ.
However, I'm curious whether my beliefs about what current EMRs actually do is accurate. Do existing EHRs prompt specifically for birthSex and only capture the gender if the birthSex is known?
Abbie Watson (Oct 12 2018 at 15:43):
We ran into this a bit with questionnaires asking about BRCA1/2 genes for mammography screening. From what I've seen in the market, it's only the newest or largest of systems that are built with genomics in mind or give consideration to birthSex/gender. There's a huge long-tail of ancilary systems that are still on the M/F/O/U model. Not to mention that the birthSex value has a bunch of political baggage and agenda associated with it; and isn't entirely reflective of the underlying biology (i.e. AIS as an example).
Instead of renaming, would a "OneOf" option be possible?
Cooper Thompson (Oct 12 2018 at 16:49):
Gender refers to a social construct, and sex refers to a biological characteristic. Since the desired data is a biological property, sex seems much more appropriate than gender. I'm mostly ambivalent about sex vs. birthSex, but gender just seems incorrect. Even if it doesn't necessarily align with current practice, doing better than current practice in the FHIR spec is one way we can nudge the industry in the right direction.
Lloyd McKenzie (Oct 12 2018 at 16:49):
Many things are "possible" :) The question is "what's core?" - i.e. what do most systems do? We already have an extension that lets you capture full-blown Observations for things like genetic results - or chromosomal gender or social gender or whatever other variety might matter in certain situations.
Michelle (Moseman) Miller (Oct 12 2018 at 17:41):
Our system uses a label of "sex"
Lloyd McKenzie (Oct 12 2018 at 17:47):
Does the UI provide any guidance on what "type" of sex gets captured?
Cooper Thompson (Oct 12 2018 at 17:48):
Recent versions of our system have two fields, one for genetic sex and one for gender identity (those are the labels on the UI).
Michelle (Moseman) Miller (Oct 12 2018 at 17:54):
@Cooper Thompson Just to confirm, you capture both for family members?
Michelle (Moseman) Miller (Oct 12 2018 at 17:54):
@Lloyd McKenzie No, I don't see any additional guidance in the UI or help documentation.
Cooper Thompson (Oct 12 2018 at 18:02):
@Michelle (Moseman) Miller yes - this is for our family history activity. One reason we capture both is so that we can label relationships appropriately. E.g. a genetic female with a gender identity of male will show up as 'parent' or 'grandparent' rather than 'mother'/ 'father'/'grandmother'/'grandfather'.
Richard Townley-O'Neill (Oct 15 2018 at 06:54):
Following one pattern for gender and sex in Patient and another in FamilyMemberHistory is asking for confusion.
I like recording what is widely available (administrative gender) in the core and what is less available, but more useful, (birth sex) in a core-defined extension.
Stefan Lang (Oct 15 2018 at 08:23):
I think the details on the element make it clear already: http://build.fhir.org/familymemberhistory-definitions.html#FamilyMemberHistory.gender
The "gender" element is defined as "birth sex" with the comment that this is ideally the case and may be unprecise.
While the actual administrative gender is important for a patient ("Do we put the person into a men's or womens's room?"), the reason for having gender/birthSex information in a family member history is medical, e.g. to help indicate genetic predisposition etc.
I also think that this is the case even when it's labeled "gender" in an UI, so birthSex seems more appropriate as this is the information that would be relevant here.
Richard Townley-O'Neill (Oct 15 2018 at 12:54):
Why call it gender if you want it to hold sex? That encourages confusion.
Cooper Thompson (Oct 15 2018 at 14:11):
The current build has the property in FamilyMemberHistory labeled as "gender", however the GF that Lloyd was commenting on is to rename it to "birthSex". That GF is not applied to the current build yet.
Michelle (Moseman) Miller (Oct 18 2018 at 22:33):
FYI - Patient Care revisited GF#17780 and voted again, this time approving a name change from gender to sex
Gabriel Bezerra (Feb 12 2019 at 12:51):
While working on value sets, I noticed that FamilyMemberHistory.sex in FHIR 4.0.0 is bound to the unstable version of administrative-gender value set: http://build.fhir.org/valueset-administrative-gender.html
https://www.hl7.org/fhir/familymemberhistory-definitions.html#FamilyMemberHistory.sex
Shouldn't it depend on administrative-gender in version 4.0.0 as well?
Grahame Grieve (Feb 12 2019 at 13:58):
@Russell Leftwich @Michelle (Moseman) Miller
Eric Haas (Feb 12 2019 at 16:04):
we discussed this on PC and landed on the current valueset. and this stuff is rarely captured to that degree of specificity as is often patient reported. In the real world is a mixed bag - who really know your Uncles Birth Sex?
Michelle (Moseman) Miller (Feb 12 2019 at 17:56):
I think Eric is describing GF#19716, but the question seems to be asking why R4 is binding to build.fhir.org....which seems to be my mistake in the FMH resource spreadsheet including a link to the wrong base URL (http://build.fhir.org/valueset-administrative-gender.html should have been http://hl7.org/fhir/...). @Grahame Grieve does this necessitate a technical correction to R4?
Lloyd McKenzie (Feb 12 2019 at 19:53):
And probably a tooling fix as well - so we catch that sort of thing going forward
Grahame Grieve (Feb 13 2019 at 10:40):
yes I think it does need a technical correction
Michelle (Moseman) Miller (Feb 14 2019 at 23:28):
PC approved GF#20393 tonight -- what are the next steps for the R4 technical correction, @Grahame Grieve @Lloyd McKenzie ?
Grahame Grieve (Feb 15 2019 at 10:45):
mark the task as 'change required' and set the target spec to R4
Michelle (Moseman) Miller (Feb 15 2019 at 14:34):
@Grahame Grieve Done. I updated target spec to R4 (status was already marked as change required) - you will take it from here then?
Gabriel Bezerra (Feb 15 2019 at 16:08):
Thanks, @Michelle (Moseman) Miller , @Lloyd McKenzie and @Grahame Grieve
Grahame Grieve (Feb 17 2019 at 04:24):
yes I'll take it from here
Last updated: Apr 12 2022 at 19:14 UTC
