Thursday, February 01, 2018

Administrative Gender Code System: The Never Ending Story

*Subject:* Re: [vocab] Administrative Gender code system

On Tue, Jan 30, 2018 at 9:35 AM, Flores, Finnie

Hi John,Thanks for questions. At this point, we plan to publish this for our reference data model/dictionary (which eventually will be implemented in solutions).

 Essentially the idea is to do this:

        For Gender the HL7 codes and displays are:

        M = masculine
        F = feminine

        For Sex at birth the HL7 codes and displays are:

        M = male
        F = female
        UN = intersex

        Is this permissible use of HL7 AdministrativeGender code system,
        particularly associating a different display for the HL7 codes?


*Subject:* Re: [vocab] Administrative Gender code system
On Tue, Jan 30, 2018 at 9:36 PM, Lisa R. Nelson > wrote:

This is a very good “case study” for how to determine when a new value set needs to be defined.  My instincts say this is a case where the right answer is to create a new value set. However, it would be good to have some guidance from Vocabular which we could use as a “perk test” to make it possible for more people to rapidly apply the test and come up the same conclusion as to if a new value set is needed or not.

Proposed approach:  As comparison questions for each concept:

     1. Is “masculine” the same concept as “male”?  No.
     2. Is “feminine” the same concept as “female”? No.
     3. Is “intersex” the same concept as “undifferentiated”? No.

If the concepts in the proposed “answer set” are not all semantic equivalents of the answers is the existing value set, then you need to make a new value set.

Is there a simple FAQ that explains how to determine if you need to make a new value set or not?

*From:* Russ Hamm [
*Subject:* Re: [vocab] Administrative Gender code system

This would not be an appropriate use of Administrative Gender which is defined as "The gender of a person used for administrative purposes (as opposed to clinical gender)" as there is a risk of these terms implying or changing the semantics of the existing codes.

It would be possible to add these as additional synonyms to Administrative Gender or create a separate value set to meet your use case via the Vocabulary Harmonization process.

*From:*Lloyd McKenzie []
*Subject:* Re: [vocab] Administrative Gender code system

From a practical perspective:

As much as humanly possible, we try to avoid multiple display names for v3 codes. The model and the tooling doesn't handle it well.  As well, this is a set of codes that are extremely deeply used within v3 and have been established for almost 15 years.  The code system always has been broken.  "Yndifferentiated" should never have been a code in the AdministrativeGender code system - but it's not something we can reasonably yank or fix now.  And if we were to do so, it wouldn't actually manifest anywhere - there are very few new v3 specs being created and those that do get updated will likely require the display names align with what was previously used.

If we were going to propose new display names (or codes) for something, the place to do that would be FHIR which isn't (quite) normative yet.  FHIR has no concept for undifferentiated/intersex because that's not an administrative gender. I don't think we would change from male/female to masculine/feminine because those aren't "genders".  They don't align with what gets captured in administrative systems, on drivers licenses, in passports or all the other places "administrative" gender is represented. Masculine/feminine sounds more like "social" gender to me - and that's a different element.

*Subject:* Re: [vocab] Administrative Gender code system
Am 31.01.2018 um 05:37 schrieb McDonald, Clem (NIH/NLM/LHC) [E]:

For the record, I think the choice of  Undifferentiated a goofy mistake made out of haste and lack of subject matter content by whom ever made it. I believe the codes were M, F and U, and someone guessed wrong on U.  Which always meant unknown by the recorder.  Undifferentiated is a very specific term applied to new born infants. It is used when the   care givers are asked to make a call on the gender (sex) of the child and the  genitalia are in a midle state between Make and female – hence undifferentiated.

*Subject:* Re: [vocab] Administrative Gender code system
On Wed, Jan 31, 2018 at 10:05 AM, Frank Oemig wrote:

Value Sets Management
We are currently working in the UTG and VSB projects to get a better understanding how value set management works. Everyone has an idea, but those vary. We need an information model to handle definitions, expansions, constraints, binding and usage.

Value Set creation
Of course, a value set can contain multiple codesystems, perhaps with the same codes from different codesystems. This is not an issue.

Administrative Gender
This term is misleading. It has nothing to do with patient gender. It is aka of room indication. So I agree with Lloyd and Clem. For that purpose "male" and "female" including "unknown" are enough. You could replace male and female with "room-mate male" and "room-mate female"...

Different Gender Interpretation Types
The problem with our gender discussion is that we never agreed on a common understanding. It has nothing to do with value sets, but code systems.
Some believe that patient administrative gender represents the gender of the patient. This is quite convenient, but wrong. This is the reason why we have introducted "undifferentiated" because some injects different views into this field. IMO, any statement about patient's gender - no matter which interpretation counts - should go into different observations. (This is what Clem implicitly said.) For that purpose we need different code systems. Most of them will contain a code for "male" or "female", but with different interpretations. Stating "male" is a different concept compared to my passport also stating "male". The display name is the same, the code may be the same, but the concept is definitely different. Therefore we need different code systems.
I believe moving in that directions will solve the problem. (So, please, review that URL although the contents is in German.) But I also know that staying with what we currently have and do is more convenient. Consequently, this discussion will come up at least every year again.

No comments: