Propose to use https://build.fhir.org/ig/HL7/UTG/ValueSet-sex-parameter-for-clinical-use.html instead birthsex

[mingward]

What were you reviewing?

https://nih-ncpi.github.io/ncpi-fhir-ig-2/StructureDefinition-ncpi-participant.html#profile

Relevant Link:

current:
https://hl7.org/fhir/us/core/STU3.1.1/ValueSet-birthsex.html
Propose:
https://build.fhir.org/ig/HL7/UTG/ValueSet-sex-parameter-for-clinical-use.html

Feedback:

dbGaP study participant sex is reported, not always birthSex.

Suggested Improvements:

How about using:
https://build.fhir.org/ig/HL7/UTG/ValueSet-sex-parameter-for-clinical-use.html

Thank you!

[RobertJCarroll]

I believe the use case you describe is already covered by the default "administrative gender" field, which uses the male/female sex labels and is suitable (in my opinion) for reported values that are not well described in how they are collected (eg, via karyotype / self-reported / etc).

The goal of adding this additional extension was to enable a more specific semantic option when available. We can definitely revisit the approach of using such extensions and review the list of ones we would like to highlight for the IG. I think this applies to the "population" or "ancestry" type fields as well- eg, perhaps we should add explicit reference to a "predicted genomic ancestry" type of extension.

[RadixSeven]

When one uses an extension with specific semantics like birth sex, one should follow its semantics. However, in most cases, we are not working from a birth certificate or a prenatal observation, and even if we are working from a birth certificate, it may have been altered since birth.

Sex Parameter for Clinical Use crucially allows the user to supply a source. For dbGaP, that will usually be "Sex as provided by the study authors" or "Chromosomal sex determined by insert criterion here".

Admittedly, this is a compromise. The fully semantically correct field would be RecordedGender. However, that extension is complex enough that users would have trouble with it. But most users can use the Sex Parameter for Clinical Use the same way they'd use the Us Core Birth Sex extension (i.e., looking at the value slice). However, an optional field would be available if a user wants to be careful about the semantics. The deviation from the correct semantics is that users are not making a clinical decision; they are making an analytical decision. However, since there is no way to specify the decision being made, that ambiguity is baked into the extension. So, it is not a violation that will degrade the community semantics substantially.

I believe the use case you describe is already covered by the default "administrative gender" field,

The administrative gender value set is used by Patient.gender, and it explicitly concerns gender, not sex. It says, "Administrative Gender - the gender that the patient is considered to have for administration and record keeping purposes." It continues by saying, "The gender might not match the biological sex as determined by genetics or the individual's preferred identification."

These are two different fields. It is common (at least as much as minorities can be "common") to have Gender: other and Sex: male or Sex: female. I know three people with this combination and several others who might fit but for whom it never came up in conversation.

One of the faults of the FHIR Patient resource is that it does not allow for recording sex, a critical variable in a medical context. So, EHRs are hopelessly muddled, with some recording gender and some going against the semantics and recording sex for practicality. (dbGaP currently uses that field for sex - though I hope to change that.)

If we leave the extension as "Birth Sex," we will create the same muddle. People will not be able to trust a Birth Sex field because it does not mean "birth sex." It will mean whatever the data providers decided was "close enough." There will be no way to tell if the data provider means "birth sex" or if they mean "submitted sex." People who want clean data will need to create yet another extension that careful providers will use.

It is better to write the standard so that the easiest way to fulfill it is to use correct semantics. In this case, the least-effort option is to fill out the required "value" field and omit the other fields. This will tell users that the value was "sex" but of unspecified provenance. However, providers with more information can explain their source in the supportingInfo slice. And it also leaves room for information from specialized studies involving transgender patients who might be considered female based on hormone levels but male based on chromosomes and other similar edge cases.

And for those providers who DO have birth sex, that can be accommodated in the supportingInfo slice of Sex Parameter for Clinical Use. We can even include a profile-specific version of the extension with particular codes chosen to represent "Birth sex" and "Sex as provided by the study authors" using an extensible or preferred binding strength.

[RobertJCarroll]

Thanks for the feedback. I think there are a few potential strategies for managing this that we can consider, and you've highlighted some. We're flagging this for further follow up as I discussed.

Two things I'll comment on now:
I'm not recommending we conflate sex and gender identity. The ambiguity and administrative nature of the Patient.gender field is why I suggest it's broadly suitable for our data. In my experience working with extant research data data, studies haven't recorded sex and gender identity explicitly, and the reported values and protocols for establishing them are mixed among studies (just like they have been in the EHR setting). The general model I'm suggesting is "use the administrative reporting field for the studies' administrative reporting", while also providing options for more explicit semantics. We added the birth sex extension as that lines up with the self-reported options from AoU; it's certainly not the only approach. If we have details about the measures used we should record them! There is more info about strategies here, which I imagine you have referenced but others may find helpful: https://hl7.org/xprod/ig/uv/gender-harmony/model.html

I'm a little leery of SPCU in our setting. IE:

Definition: A Sex Parameter for Clinical Use is a parameter that provides guidance on how a recipient should apply settings or reference ranges that are derived from observable information such as an organ inventory, recent hormone lab tests, genetic testing, menstrual status, obstetric history, etc. This property is intended for use in clinical decision making, and indicates that treatment or diagnostic tests should consider best practices associated with the relevant reference population.
We'd have to have very strong confidence in the data to make the level of assertion happening here, and I'm not sure I've seen a research dataset that I could confidently interpret into male-typical and female-typical values as there is not enough information recorded. Given your suggestion to lean on the source, RSG seems to be more fitting given our contexts if we want to have a model that supports clarity on the different kinds of reports.