*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?
Thanks
Finnie
*Subject:* Re: [vocab] Administrative Gender code system
On Tue, Jan 30, 2018 at 9:36 PM, Lisa R. Nelson
> wrote:
All,
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?
Lisa
*From:* Russ Hamm [mailto:russellhamm@gmail.com
*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.
-russ
*From:*Lloyd McKenzie [mailto:lloyd@lmckenzie.com]
*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.
Lloyd
*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.
To: vocab@lists.hl7.org
*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.
regards
Frank
