Sex and gender are important health determinants. It is therefore valuable to represent them in medical records. However, these entities are complex to define. In this paper we review some existing representations of sex and gender, with a special focus on the informational entities representing them. We detail our proposal for formalizing sex and gender informational entities according to the OBO Foundry methodology. In particular, we introduce classes enabling to represent information that may be either well-defined or ambiguous relatively to whether they represent sex or gender.
The terms “sex” and “gender”, despite having clearly different meanings, are still
sometimes used interchangeably in some contexts to characterize a human individual.
While “sex” refers to characteristics that are biologically determined such as
chromosomes distribution and reproductive/sexual anatomy and physiology, “gender”
refers to socially constructed characteristics [
Sex is commonly categorized as female or male, especially in administrative documents, but there is a great variety of biological categories beyond those two. There is also a considerable diversity in gender differentiation, depending on how people perceive themselves (gender identity) and how they express their gender (gender expression).
Evidence of sex and gender differences have been reported in chronic disease,
physiological processes and the impact of lifestyle on health [
Learning Health Systems (LHS) are conceptual frameworks that enable the tight
coupling of care delivery, research and knowledge transfer. Starting from data generated
through care delivery, research results are more likely to be relevant and the findings are
re-injected in care through knowledge transfer processes like audit/feedback tools and
decision support tools. This then triggers a new cycle [
As part of the LHS PARS3 (“Plateforme apprenante en recherche en santé et en
services sociaux” - https://griis.ca/en/solutions/pars3), we have developed several
ontologies for various domains, such as the Prescription of Drugs Ontology PDRO [
Many electronic medical record systems integrate sex and gender information into patient demographic information. However, most medical records still only specify the sex of an individual, often labelled “sex assigned at birth”, without providing the whole spectrum of possible biological sexes, or the possibility to specify a gender instead of a sex. Sometimes a field asking to choose “M” or “F” will not even specify explicitly whether it refers to sex or gender. Given the ambiguity surrounding both data capture (e.g. unclear question) or data storage (e.g. a database field labelled “M-F” without other information to clearly understand the nature of the information stored in the field), our ontology needs to be flexible enough to allow annotation of ambiguous data elements while providing the means to annotate with a much higher degree of precision. In this paper, we review existing terminological and ontological representations of sex and gender, detail our proposal for formalizing sex and gender informational entities in our demographic data ontology DEMO, and discuss some of its implications.
Distinction between sex and gender is acknowledged in the major international health
standards such as HL7’s Fast Healthcare Interoperability Resource (FHIR) or SNOMED
CT [
While many health care standards provide distinct terms or placeholders for sex and
gender, the definitions chosen for these elements make them more challenging to
integrate into an ontology. For example, in the version 4.0.1 of FHIR, at least three
elements are available for gender: administrative gender, person gender and patient
gender. administrative gender is defined as: “The gender of a person used for
administrative purposes.” An extension adds patient gender identity defined as the
gender the patient identifies with. The value set for patient gender identity contains more
choices than for patient gender above. It is important to note that while these four
elements contain the term “gender” and refer to it in their definitions, the term “gender”
itself is never defined, leaving much uncertainty around the terms. Moreover, it is not
clear whether the term refers to gender itself or to an informational entity that is about a
gender. Lastly, the use of field value “Other” adds an epistemic dimension incompatible
with a stable ontological representation (as the extension of the class “Other” depends
on the extension of its sibling classes, which might change if new sibling classes are
introduced [
The gender, sex and sexual orientation ontology (GSSO) identifies, categorizes and
associates to other terminologies thousands of terms related to gender, sex, and sexual
orientation [
Biological sex is formalized in the Phenotype And Trait Ontology (PATO) [
depending on whether the biological sex quality inheres in the bearer’s composition of sex chromosomes or the physical expression of sexual characteristics.
Sex and gender classes in these ontologies are quality or social roles. However, related information content entities are necessary to support our LHS as explained above.
Informational entities about sex are represented in the Vaccine Ontology (VO) [
defined as: “A measurement datum that represents the biological sex of an animal.” Subclasses have been created for representing ICEs about multiple sex kinds. For example: VO:female biological sex datum=def. “A biological sex datum that represents the biological sex of an animal (including human) as being female.”
Terms referring to informational entities related to gender can be found in the
Ontology of Medically Related Social Entities (OMRSE) [
As part of our ontology suite to represent clinical informational entities, we are developing an ontology, named “DEMO” (stands for DEMographics Ontology) that focuses on demographics data, including sex and gender. Our goal concerning those latter data is threefold: • To formalize different informational entities about sex and gender; • To not be limited to a male/female or man/woman binary representation, but be able to represent the other possibilities within sex or gender; • To be able to annotate electronic health records containing representations that are ambiguous with respect to whether they refer to sex or gender (such as a field with two values ‘M’ and ‘F’, without more specifications about what those refer to).
In accordance to the OBO Foundry methodology, we imported the pre-existing classes mentioned above (*) in our ontology. However, those classes were limited to binary alternatives (man/woman for gender, male/female for sex) and we proposed to VO and OMRSE representatives to add classes about biological intersex and non-binary gender. As a result, the following classes were created and imported by DEMO: • VO:intersex biological sex datum=def. “A biological sex datum that represents the biological sex of an animal (including human) as being intersex.” • OMRSE:non-binary identity ICE=def. “A gender identity ICE that is about some person’s identifying as non-binary in gender.”
To take into account ambiguous representations of sex and gender, we created the class DEMO:biological sex or gender identity ICE=def. “An ICE that is intended to denote a biological sex or a gender identity.” This class is defined as a class equivalent to:
to account for multiple possibilities: DEMO:female biological sex or woman gender entity ICE, DEMO:male biological sex or man gender entity ICE, and DEMO:intersex biological sex or non-binary identity ICE. These subclasses are defined as “A biological sex or gender identity ICE that is intended to denote a female [resp. male, intersex] biological sex or a woman [resp. man, non-binary] gender identity”.
The addition of informational entities about intersex and non-binary gender enables us to capture more diverse information about patients’ sex and gender. Alongside “male”, “female”, “man” and “woman”, they allow us to represent field values representing intersex, hermaphrodite or gender-fluid identity for example.
Moreover, when we are confronted with records where these fields are insufficiently defined, the biological sex or gender identity ICE class works as a catch-all solution. For example, if we have a data source with an undefined field labelled “Sex/Gender” and its possible value are “M” or “F”, we can state that this field is about a biological sex or a gender. If this field has the value “F” for a given patient, we can classify it as an information content entity that denotes a female biological sex or a woman gender. While such data constructs are undesirable because of their ambiguity, they are certainly in existence; therefore, not allowing data access to such fields would not be acceptable to users.
To represent ambiguous information, we could have instead introduced a class ambiguous biological sex or gender identity information content entity, whose instances are ICEs that denote ambiguously to either a sex or a gender. However, the ambiguity depends on the context and the receiver of the information: a piece of information can be ambiguous for a user (say, someone who is retrieving the information from an institution to which she does not belong), and non-ambiguous for another user (say, someone who knows how the database has been built). Therefore, the representation of an epistemically charged notion like an “ambiguous” representation is much more complex, and it is not clear that such complexity would bring commensurable gains. This is why we introduced the catch-all class biological sex or gender identity ICE.
Axioms using the IAO:is about relation should also be added in the future [