Has anyone else had any experience with HL7’s Gender Harmony IG. They are proposing 5 data elements they propose to collect, and I’ve been looking at how it aligns with our current Gender archetype.
‘Gender identity’ - seems well aligned.
‘Pronouns’ - seems well aligned.
‘Name to use’ - is not part of the Gender archetype and is more aligned with formal demographics management from our POV.
‘Recorded sex and gender’ - I quite like this concept as a potential enhancement or replacement for our ‘Administrative gender’ data element (which we had aligned with previous HL7 work), as a ‘bucket’ for the mess that is the ambiguous, unspecified, poorly specified, or poorly recorded, sex and gender records. Unfortunately, it also currently includes ‘Sex assigned at birth’ (SAAB), which I still think is quite distinct and clinically important. SAAB is a solid data element for recording a life-long baseline from an anatomical/ biological/genetic POV, especially when compared to a current self-declared ‘Gender identity’ to highlight alignment (cis) or divergence (trans).
Sex Parameter for Clinical Use (SPCU) - I find this concept rather troubling. It is intended to be used in specific contexts, mainly targeted towards lab and imaging order entry as I understand it. The intent is for the referring clinician to classify/label the patient as ‘male-typical’, ‘female-typical’ or ‘specified’ (with links to relevant evidence/observations) for the purpose of the specific order only. The categorisation is effectively lumping a range of clinical parameters/observations that includes organ inventory, recent hormone lab tests, genetic testing, menstrual status, obstetric history, pregnancy status etc under a single category that will be used to trigger the application of appropriate reference ranges, interpretation of a test result, or support/ensure appropriate radiation shielding by the receiving organisation.
I’m particularly curious about what other clinicians and SMEs think about SPCU in terms of clinical accuracy and safety.
Definitely agree with your assessment, Heather . though I actually prefer Administrative rather than Recorded, since I would hope that Administrative is about what needs to be recorded (for good or bad) to align with jurisdictional requirements.
I share your anxieties about SPCU but I can also see its value/ need when (again rightly or wrongly) a lot of safety protocols and reference ranges take a binary view.
I like the idea that it can be applied contextually, ‘in the context of this lab test’ or ‘this imaging study’ and even has the option to say basically ‘its complicated’.
So, on balance, I think I’m in favour. The alternative is to provide the lab etc with the background complex biological data/ circumstances so that they can decode, but the requesting clinician is much more likely to be able to make that judgement, and be able to involve the patient in the discussion.
As I understand it, the Sex Parameter for Clinical Use, will only be used when there is a mismatch between the Administrative/Recorded Sex or Gender and on how the receiver should treat the sample/set up a device/perform a procedure/interpret the result. SPCU is described “In cases where there is a patient level SPCU, the patient level value can be used as a default”, so it will only be relevant when there are exemptions. So the “female-typical” and “male-typical” values are in practice redundant, unless one want to mark that there is a discrepancy.
From a patient integrity perspective that can actually be positive, as the requester only tell for example an external lab, “treat this sample differently from what is said in the recorded sex, don’t ask why”. No reasons needed.
On the other hand, the “Specified” value allows to go into details, but should only be used when there is a good reason.
I find this post quite interesting as I have recently finished the requirements’ analysis on the gender. Based on this analysis, gender could be specified using three different dimensions:
Genotype: The genetic marker of a person. This parameter is rarely recorded and is centered around pediatric, genetic and oncologic use cases.
Phenotype: Represents the usually recorded gender by a healthcare professional either by checking it or just assuming the gender of a patient.
Sociotype: Represents the gender identity of the patient. Currently, I would use the value set proposed by the Austrian government, as the Swiss government is still trying to figure this out. And I expect Switzerland just to take over what other governments decided to do.
And thanks to this post I got a glance at the archetype Gender and I realize how administrative-focused it is, instead of representing the clinical aspect.
Based on your post, the HL7’s Gender Harmony IG document and my understanding of the socio-medico aspect of gender, the “Sex Parameter for Clinical Use (SPCU)” would represent the Geno- or Phenotype of the patient. And I would have specialized the Gender archetype to include these two dimensions more specific to the clinical use cases, by adding Genotype and Phenotype as fields to the archetype. Here a snapshot of my xmind:
Genotype is intentionally not represented in the ‘Gender’ archetype. The misuse section points towards lab tests for recording this - “Not to be used for recording genetic or chromosomal sex. Currently this is usually recorded as a laboratory test result. Formal representation of ‘Genetic sex’ is not yet well defined and may involve the combination of information axes, including chromosomal and receptor data, mosaic variants and diagnoses.”
We were not sure if it is possible for the determination of phenotype to be understood and assigned consistently by all clinicians. So we designed the data elements that reflect common clinical practice, using ‘Sex assigned at birth’ as a proxy for ‘anatomical or biological sex’ and the way some think of phenotype. It reflects estimates that in 95%+ of situations visually assigning ‘anatomical or biological sex’ can be done by direct observation of external genitalia at or soon after birth. This may need to be revised retrospectively in some situations as more information comes to light eg more information about incongruent internal reproductive organs, hormones, genotype results etc. Values are male, female, intersex, and indeterminate (usually only temporary for newborns until further testing is completed) - as per what eventually gets sent to a birth registry for the initial ‘Sex’ registered on the initial birth certificate.
Not sure what you mean by sociotype - is this synonymous with gender identity (male/female/non-binary etc) or expression or something else… but I’m assuming this grouping is self-identified and potentially changing/evolving over the lifetime? Or is it something different?
“Sociotype” is a term I’ve introduced to denote the gender identity of an individual, aiming for consistency with “genotype” and “phenotype.”
Considering your feedback and referencing HL7’s Gender Harmony Implementation Guide (IG), I would have applied on the following three options:
Specialize the “Gender” archetype to include “genotype,” noting this approach introduces a breaking change as it removes the chromosomal sex statement in the misuse section.
Develop a new archetype for “Clinical Gender,” addressing the use case outlined in “Sex Parameter for Clinical Use (SPCU).”
My preferred option: Establish a “Cluster” archetype encompassing the criteria set forth in HL7’s Gender Harmony IG. This approach draws on similar reasoning to that discussed for “Age” during the Norwegian Work Group Meeting on February 1, 2024.
I have a question about gender/biological sex representation in scores and scales.
Many scores include a value “Biological sex” (or similar in name but the same concept) that influences the total score calculation. Examples include CHA₂DS₂-VASc score, EuroSCORE II, STS score, etc.
Should observation archetypes that are designed to capture such scores include a dedicated data item “Biological sex”, or should this be represented by the Gender archetype?
For comparison, in NEWS2 archetype elements like pulse, oxygen saturation, and temperature are included as data items within the archetype, even though standalone observation archetypes for each of these also exist.
On the other hand, in the CHA₂DS₂-VASc archetype sex and age are not included even though both influence the score (I see it is still version 0, but still worth noting).
The same question is relevant to the age representation.
I believe it would be helpful to include this information in the scores and scales style guide.
hey we do some scores:
We use Gender cluster for that, usually we also record that as a part of the anamnese along with birthdate, so we dont have to do messy demographics back and forth (in the end these are kind of observations ).
For the score i would either query that then from the field to calculate the score (check if there is a gender provided, thats how we do it) or add it to the archetype itself using the cluster.
In general clusters are always preferable due to better interoperability over adding additional fields (since its better standardized then coming up with a new field).
It is a bit of a grey area and I would of course always use existing data to populate the score, if possible but … exceptions …
The score my use a different set of definitions / codes. e.g the score may define biological sex explicitly differently.
The score implicitly includes e.g a Gender code with a related numeric, and may insist on these being represented directly in the score. The Chadvas archetype is a good example here.
The items in the score are derived - - the pulse, resp rate etc items in NEWS2 are not the actual observed rates but derived scores based on ranges.
Having the gender recorded in the context of the score makes it much easier to share and reuse the result and describe calculation of a total score.
So , in general, I suspect I might explicitly model the Score sex/gender’ item but aim to populate it automatically. i.e add it to the Chadvas archetype via e.g something a GDL.
I would probably include it in the score archetype, as it is likely that the gender/sex is associated with a specific ordinal value, used to calculate the score. We also have a challenge in showing these score archetypes to the original authors, who expect to see their datapoints inside the archetype and described accurately
I agree. For all of the exemplified scores, the recorded information about gender is a category associated with a numerical value, and not the category by itself. This is similar to how ACVPU or “Air or oxygen?” is represented explicitly in the NEWS2 archetype instead of reusing the ACVPU or Inspired oxygen archetypes.
This is our experience as well, and an argument for representing the score/scale verbatim in a single archetype.
I guess the broad majority of openEHR users have missed that the original Gender CLUSTER is deprecated and replaced with EVALUATION.gender. This were done in April 2019: Clinical Knowledge Manager
The log for the new EVAL says: “Previously published CLUSTER.gender has been updated and converted to this EVALUATION archetype as it will not likely be nested within other archetypes but be used as a standalone archetype within a template.” Clinical Knowledge Manager
This EVAL may still be used to populate a Sex/Gender item in a score or an other archetype.
Note that the Gender archetype is much broader than ‘Biological sex’ or ‘Sex assigned at birth’. Please also note the Misuse section about Genetic sex, which at least for now will be a laboratory result, with a variety of interpretations and diagnoses.
Yeah in the end gender is here not for recording and more for providing information.
One should add a notion that this should be extracted if possible from EVAL Gender.
Hi all,
While researching for general sexual anamnesis related achetypes, I came across this thread—even though it isn’t entirely on point. Could you please recommend which CKM archetypes or templates are best suited for capturing adverse sexual experiences and indicators of domestic violence or abuse?
Do you have some specific clinical requirements that you need to model? If so, please feel free to share
I’ve tried to investigate how best to model this tricky area a number of times during the past few years, as well as other related SDOH topics. It has clinical, medicolegal, mental health issues amongst as well as potentially increasing risk for the patient if the perpetrator gets access to the record. And I haven’t been able to find any recommendations on what should be recorded in the clinical setting where records could be subpoenaed for legal purposes.
I’ve asked clinician friends who specialise in managing patients who are experiencing domestic violence what should be recorded in an EHR and unfortunately, no one responded. Perhaps this information is not recorded at all. Certainly I don’t think there are agreed data sets that I have been able to locate.
In the SDOH modelling I’ve been doing, we’ve established that a ‘Personal safety summary’ will be a useful basis for modelling a range of risks related to violence at home, in the community, at work etc. It may be a risk due to where they live or a violent partner. There is currently one data element which is only a narrative description - Evaluation Archetype: Personal safety summary [openEHR Clinical Knowledge Manager]
If you have some specific clinical requirements that may be useful as structured data elements within this archetype, please let me know.
Otherwise there are a couple of very rudimentary models
a Sexual health summary (although @varntzen may have access to a more advanced version that was used in a Norwegian EHR a number of years ago) and
My current focus is on sexual health related topics (i.e., STIs, contraception, etc), driven by the structure of existing questionnaires. I am working backwards from the existing questionnaires and workflows for sexual health consultations to build openEHR templates using the available archetypes (using the designer tool). I started with a general sexual anamnesis set of questions that I have covered by what is already available (cap the ones I have asked for). I am using:
Sex & Gender Evaluation: capture sex at birth and current gender identity).
Sexual Health Screening Questionnaire: capture sex partners and their gender.
Referral review admin: capture if the patient has been referred from a known/unknown healthcare provider.
Vaccination status observation: capture the HepB vaccination status for now.
As you suggested, Sexual Health Summary evaluation: capture information on previous/current partners.
Following this, I am thinking to move towards the sexual health related topics (starting with STI related data) mostly focusing on SOAP protocol exchangeable structured data and how these map to the archetypes.
@varntzen are there more archetypes from your previous work we can add to CKM. The awkward conversations in creating them should never have to be repeated. TMI .
A lot of them are more check lists and in Norwegian language only. The more STI-related are in both English and Norwegian, but in no way modelled according to the style we model today. However, they sparked a lot of work that later ended up as a pattern for other archetypes.
We experimented with design to cater for outlier questions, for example to record to what extent the individual and their partner used protection against STI in different settings (which body parts were in contact with which body parts). Cluster Archetype: Seksuell kontakt [Nasjonal IKT Clinical Knowledge Manager]. I do hope the Olafia clinic doesn’t use that today.
Due to lack of finance and time, the archetypes were never finished and published. Today, they can mainly serve as ideas of data which belong in a STI consultation. If we get the finance, we will redo the whole module. I guess we will use the recent screening questionnaire pattern, as much of the information is self reported. In addition, Physical examination findings family of archetypes, symptom/sign, and medication archetypes.
).
.