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.