(The second in a series of posts by
William Hogan)
In my last post I showed, on the basis of the example of marital status, how standardization of demographic information is challenging and how typical information-modeling techniques fail to help the problem.
In this post, I show how HL7 handles gender. Again, we will see difficulties for standardization. Additionally, we will see resultant hindrances to informatics support of humane, competent patient care.
First, we must review how the HL7 Reference Information Model (RIM) structures demographic information. It does so primarily by structuring the information as “attributes” of key “classes”, including LivingSubject, Person, and NonPersonLiving-Subject. The latter two classes, according to HL7, “specialize” the LivingSubject class.
The HL7 definitions of these classes are relevant to our understanding of gender, so I reproduce them here.
LivingSubject: An organism, alive or not.
Person: A human being.
NonPersonLivingSubject: A subtype of LivingSubject that includes all living things except the species homo sapiens.
Next, we need to note that the RIM represents gender as the administrativeGenderCode “attribute” of the LivingSubject “class”. We also need to review the HL7 definition of this “attribute”:
The gender (i.e., the behavioral, cultural, or psychological traits typically associated with one sex) of a living subject as defined for administrative purposes.
We are then told of just one such administrative purpose: … the appropriate allocation of inpatient bed assignment.
Problem #1
First, a minor problem. Note that administrativeGenderCode is applicable to all organisms (LivingSubjects), not just human beings. However, the only administrative use case we are given for this attribute is hospital bed assignment, something relevant only to humans. Even if veterinary hospitals assigned “inpatient beds” to animals (as opposed to cages or pens), placing two animals in the same enclosure is the exception not the rule.
Which raises yet another problem.
Problem #2
For humans, single rooms now, too, have become the rule and not the exception, at least in the United States. With the only stated use case for this “attribute” fast becoming a relic of the past, should it remain? I am also struggling to imagine other, non-clinical, administrative uses for administrativeGenderCode.
But larger, much more relevant and important issues loom.
Problem #3
What are we to do for recording gender for “non-administrative” purposes, such as patient care? We are told in the notes for administrativeGenderCode that:
This attribute does not include terms related to clinical gender. Gender is a complex physiological, genetic, and sociological concept that requires multiple observations in order to be comprehensively described.
Thus we find out that, even for humans, the administrative-GenderCode “attribute” is not relevant for recording someone’s true gender! Why not instead call the attribute “bed assignment instruction” (or bedAssignmentInstructionCode), and have values “male bed” and “female bed”?
Here, HL7 has essentially recommended to us more than one way of recording a patient’s gender, with obvious implications for interoperability (more than one way to record something is always a risk to interoperability).
And how are we to record “clinical gender”? The RIM does not tell us (not here, anyway). It is not an “attribute” of a “class”, so presumably we must record it as an “Observation”, a different “class” in the RIM. But then we are allowed to record gender in any of the following non-interoperable ways, even when using HL7 and standard terminologies (with thanks to
this document):
Obs.code | Code description | Code terminology | Obs.value | Value code description | Value code terminology |
263495000 | gender (observable entity) | SNOMED CT | 248153007 | male (finding) | SNOMED CT |
365873007 | gender finding | SNOMED CT | 248153007 | male (finding) | SNOMED CT |
248153007 | male (finding) | SNOMED CT | ---* | --- | --- |
---* | --- | --- | 248153007 | male (finding) | SNOMED CT |
21840-4 | Gender | LOINC | 248153007 | male (finding) | SNOMED CT |
* The value in these cases is simply omitted, as opposed to being populated with one of HL7’s “flavors of null”.
Problem #4
But there is something wrong with my table above. The SNOMED CT code for “male (finding)” above is for the sex, not the gender of the individual. I was forced to use it because SNOMED CT provides no codes for male or female gender (although it does provide codes for “unknown gender” and “gender unspecified”). The code for “male” that I used in the table is a child of “finding related to biological sex”.
The World Health Organization explains sex and gender as
follows :
“Sex” refers to the biological and physiological characteristics that define men and women. “Gender” refers to the socially constructed roles, behaviours, activities, and attributes that a given society considers appropriate for men and women.
To put it another way:
“Male” and “female” are sex categories, while “masculine” and “feminine” are gender categories.
We can further distinguish, at a minimum, phenotypic vs. genotypic sex, where the former refers to one’s gross anatomy and the latter refers to the configuration of sex chromosomes in one’s cells (XX vs. XY vs. anomalous configurations). It is possible to have female genitalia but a genotype of XY, for example, due to androgen insensitivity syndrome. Thus the distinction is real and worth making in EHRs. It will certainly be important for interoperability of data generated by chromosomal analyses.
In addition to SNOMED, both HL7 and LOINC also confuse gender and sex. For one, in previous versions of its standards (including the RIM), HL7 referred to this attribute as “administrative sex”. Furthermore, the HL7 NonPersonLivingSubject “class” has an attribute called genderStatusCode, defined as: The state of the primary reproductive organs of a non-person living subject. But of course, the state of an animal’s reproductive organs (and I am not really sure what this means, are they talking about spayed and neutered pets, for example?) has to do with its sex, not its gender. Recall that HL7 defines gender as …behavioral, cultural, or psychological traits typically associated with one sex.
LOINC has codes labeled “gender” for the sex of a baby as observed on ultrasound. It would be difficult indeed to elucidate, even by ultrasound, the “behavioral, cultural, or psychological traits typically associated with one sex” of a fetus. Codes 11882-8 and 11883-6 both have gender as the attribute measured by ultrasound (the “component” in LOINC-speak) but have a “related name” of ‘fetal sex’.
Problem #5
Now, some may say that the distinction does not really matter for “all practical purposes”. And true, in practice, it is only the administrativeGenderCode that gets collected and included as structured data in the EHR, claims submissions, hospital discharge data sets, and so on.
But this is a problem and not a virtue. For many practical purposes, it leads to great confusion and causes problems that physicians take seriously. For example, there was a recent listserv discussion of the Association of Medical Directors of Information Systems on gender vs. sex and how it applies to transgendered and transsexual individuals. One physician describes the following real-world, practical, scenario:
I don’t think there is a clear standard [with respect to representing sex and gender]. For what it is worth, I have a long term patient who went through this, male to female. There is a non ICD diagnosis in [our EMR system] (which I think you use) that I put on the problem list saying “History of sex reassignment male to female.” In registration system gender is as female, but we have discussed that we might need to change that back to male for medical coverage of some conditions in the future or face non coverage and higher [self] pay.
Like most, our preventive reminders aren’t sophisticated enough to pick up the unique issues here, so Pap smears are manually permanently deferred on this patient.
Our organization takes the view that we enter the gender race and ethnicity that you say you are.
So our state-of-the-art EHRs cannot even represent sex vs. gender, let alone reason appropriately with the data or exchange sex and gender data in an interoperable way. And HL7 and related terminology standards offer us no assistance, and even hinder us, in this regard.
With the net effect that our entire healthcare information system is really using an attribute—intended only for gender-specific bed assignment, an increasingly irrelevant task—for patient care, setting health care policy, and numerous other secondary uses of “administrative-but-forced-on-physicians-and-patients-as-clinical-at-least-in-part-because-IT-vendors-and-IT-departments-and-standards-organizations-cannot-figure-out-sex-vs-gender” data.
