Clair's Outline for Terminology

snomed_recommendations_v6.docx (Version 6.4)

Individual changes discussed will be made from now on using a "UPDATE DD-MM-YYYY" system. So if a change was proposed on today's call, it would be indicated using "UPDATE 03-17-2021".

Please include individual discussions about the content of the document in other discussion topics. If a discussion topic does not seem applicable, please create a new discussion topic and tag me with the changes you are requesting or any comments/concerns/questions, etc. I am also available at my institutional email, kronkcj@mail.uc.edu.

Updated with partial changes based on today's call for modeling perspectives, with changes to be made noted (will be finalized in 6.10). The document is necessarily incomplete, please continue to comment if you have any questions or concerns about usages in various spaces.

snomed_recommendations_v6.9.docx (Version 6.9). This version incorporated feedback based on last month's and this month's meeting, as well as feedback from the Queer PhD Network (~7,800 members), Trans PhD Network (~1,800 members), and the International Transgender Health (~8,300 members) groups on Facebook, as well as to select members of the American Medical Informatics Association (AMIA) community, thereby including perspectives of LGBTQIA+ persons and their providers. I will be sending out version 6.10 to several intersex advocacy organizations once I have finished building out that part of the hierarchy, including interACT, interConnect, Organisation Intersex International Chinese, OII Europe, ILGA Europe, and ILGA World. Please let me know if you have other organizations in mind that you would like me to reach out to.

HI Clair Kronk,

I have been reviewing your terminology document version 6.1, which I know isn't the newest version, but is current enough for the purposes of the questions. Looking at the Recorded Gender finding group starting on page 12, these concepts appear to be best implemented as either a LOINC code (United States) that is associated with a nominal answer list or as a SNOMED Observable entity.

For argument sake, lets assume that "Recorded gender with primary health insurance" is LOINC code 1234-5. When constructing this LOINC code, the authoring terminologist ask you what concepts from this document should be represented as the selectable list of responses for the code. This answer list may have a binding strength of example (self-explanatory), preferred (The terminology recommends using this list but you don't have to), or normative (Only this answer list may be used in association with this LOINC code.

From an authoring perspective, which concepts from which section of the snomed_recommendations_v6.1 20210301.docx would you instruct the author to use when creating a normative answer list for LOINC code 1234-5 | Recorded gender with primary health insurance |?

For example, would the answer list include concepts from the "Gender Assignment finding outline" beginning on page 19 or values from another part of the purposed hierarchy document?

While this same use case could have been constructed using a SNOMED Observable entity concept, LOINC would be authoritative in the US and the answer list artifact that exists in LOINC expressly lends itself to this question. I also think the answer to this question lends itself to resolving the issue we struggled with in yesterday's meeting.  

Thanks

John

Hi John Snyder that is an excellent question. And they definitely could be implemented in either way you discuss (in terms of with LOINC or a SNOMED observable). I'd recommend an observable personally, given what you discuss further down.

I would say that preferred (for binding strength) would be the best answer list if we went with LOINC on that part (mostly because laws on the subject are rapidly updating in a number of countries, so there's no way to confirm completeness of the answer list). The list would need to include at least options for "Female recorded gender with primary health insurance", "Male recorded gender with primary health insurance", "X recorded gender with primary health insurance", and "no recorded gender with primary health insurance" in the United States. However, the additional gender assignments (in the finding outline you mentioned) could be used as that is the semi-complete list of markers I have seen in attempting to review worldwide legal documents with gender markers.

I think if the group votes that a recorded gender datum is potentially out of scope, or better suited for LOINC, then we can remove that section wholesale. I had included it because it has been something that has been asked for on the clinical side, but if it can be better modeled with LOINC, then it should be modeled with LOINC 

Best (and thank you for bringing this up!),

Clair

EDIT 1: I am adding the following note to my records, please let me know if this covers what you've stated adequately!

"""

Recorded Gender Finding

UPDATE 04-22-2021: John Snyder has suggested that this hierarchy may be out of scope for SNOMED, and easier to model using LOINC. Clair Kronk has responded to this willing to go either direction based on democratic vote, as long as the data are represented somewhere (LOINC, SNOMED, or another medical terminology system). She has suggested that this be further discussed at the May 2021 meeting to ensure quorum.

"""

Hi Clair Kronk,

Thank you for the response, but I have to admit the response isn't what I expected it to be, so let me ask some clarifying questions.

Since the context (i.e. "recorded gender with primary health insurance") is captured in the LOINC code (or SNOMED observable entity), would it be acceptable to you to remove the context from the answer list value?

For example:

If this is acceptable to you, then considering the "question / answer" type format that exists throughout healthcare implementations can the proposed terminology in your document be distilled down so that context is only captured as part of the "Question" and not redundantly stated as part of the "answer" value? Until we are able to distill out the redundant context, I am not sure we are looking at just the core set of foundation concepts that need to be represented in SNOMED.

To clarify, at this point, I am not suggesting that any content is out of of scope with SNOMED. I am trying to look at the terminology you purposed from a pragmatic implementation perspective as the starting point, remove redundancy from the purposed descriptions, and hopefully back into a list of acceptable concepts that we can all agree mean the same thing and can be represented the same way across all implementations. 

At some point, I think we will need to realistically consider which content may need to be represented in both LOINC (for the US and other countries using that terminology) and SNOMED (observable entities) as well as if any content is outside of the scope of SNOMED International and may need to be considered for a country extension, but we aren't there until we can reach a consensus decision on some of the content.

I appreciate your taking the time to consider how we might distill out redundant context and identify that core set of foundation concepts.

Thanks

John

Clair Kronk Thank you for clarifying. So that you can continue to educate me on how you envision your your purposed terminology being implemented, I am going to need to take it one bite at a time with the understanding that "female" may not necessarily mean the same thing through the entire document.

Can we distill the "Gender Assignment Finding outline" section down into the following without creating offensive terms or losing semantic meaning? 

All I did here was separate the context from the core concept, so basically making a pseudo post-coordinated expression that states (1234-1 | Gender assigned in utero| + xxxxx | Female| = 1.1.1 |Assigned female gender in utero| )

For this example, I created a pseudo-LOINC code for each sub-hierarchy in "Gender Assignment Finding outline". In reality, I think this would be better implemented as a single observable named "Assigned Gender" plus the "Age-at-encounter" to represent if that assigned gender fits into an organizations' age range definition of "childhood" versus "adolescence", but let's not get hung up on that particular point.

Again, I understand that each of the answer list value do not have a single consistent definition across the spectrum of the terminology document, but there are terms here to which I don't know the correct definition. If we break it down as follows, can you provide a single 1 or 2 sentence definition, that a layperson or data analyst could understand, for each concept.  (If we do this across each section of the terminology purposal document, i think it will clearly allow us to see the multiple definitions being assigned to the same term and determine if the surrounding context (i.e. associated LOINC or SNOMED  observable entity) is sufficient to address the change in meaning.

Primarily, the point here is for me to understand the difference between "Non-binary", "Ambiguous", "Diverse" which may or may not have overlapping definitions. The second purpose is to determine if there are predefined HL7 null flavors that may negate the need for some of the concepts within a given context?

My last question, for this post, is does "Female" mean the same thing when the context is "Assigned gender" as it does when the context is "Recorded gender with primary health insurance"?

Sorry, I know this is a big ask given the immense amount of work you have already done, but I do believe this is going to help the project along.

Thanks

John

John Snyder thanks again for all of the questions! it is totally okay to ask and I appreciate them all! I'm more used to more of the academic ontology and NLP side of things which operates a bit differently at times, and it's been great to learn more about the inner workings of SNOMED. I also sent you an email (I hope that's alright!) to potentially meet in person over the next couple weeks, if you think that might be useful!

So it is entirely arguable that an assigned sex/gender at birth value (however we want to split that up, if we want to at all) is always a "recorded gender marker on X document" (this is how HL7 has democratically decided to handle it, and I am okay with considering it as such via a similar process if people decide as such here). This may be different in different jurisdictions, which follow different procedures.

So for instance, from 1960-2000 in the United States and Canada, it was standard procedure to "reassign" infants with particular genital configurations (or, in the case of David Reimer, traumatic failed circumcision). So you would have an "assigned sex at birth" value of 'male' (based on presence of penis) in the case of David Reimer, but an assigned gender of 'female' in infancy. Reimer had a 'F' on his birth certificate, but later transitioned in life and changed documentation to 'M'. In a case series of 8 individuals found who went through this series of procedures, 7 "transitioned" to male and one later identified as a butch lesbian. So in the 7 that transitioned their assigned sex at birth (not really recorded on a document by assigned by clinicians) was 'male', then the record on the birth certificate was 'female', and gender identity was 'male'. So are these individuals really transgender? That's up for debate, but having each individual variable parsed out is helpful for providers to understand how hormone therapy or surgery might affect an individual given that individual's previous surgical, hormonal, and social history.

So looking at the list, I really don't see any problems with the gender assignment terms, so that should be alright!

So the differences here are primarily jurisdictional (with an asterisk). For instance, nonbinary is a proposed assigned gender in several Canadian, U.S., and European jurisdictions. As with "male" or "female", it isn't really defined in any legal or medical documentation how the assignment is really made. 3 ways to make these changes have been noted: (1) once individual is old enough in a given jurisdiction, they can ask for the change and get it on the spot (so usually late adolescence/adulthood assignment), (2) a parent can request nonbinary assignment at birth, and (3) an individual can present with required medical documentation of intersex status or medical/social transition to nonbinary gender (which, of course, there's no solid definitions of evidence for what such a transition looks like, because there is no set way to transition as such; so this can be a late childhood to adulthood assignment depending on jurisdiction). These changes are still in the pipeline, but will be passed almost certainly before we release the new SNOMED codes, so they need to be accounted for.

Both ambiguous and diverse are assignments specific to central Europe currently, but are most heavily utilized in Germany. There are 3 ways for a person to be assigned diverse gender in some context: (1) a person provides "adequate" medical documentation of an intersex condition (up to jurisdiction what this means; it may just be a letter that says "my patient is not male or female), (2) a person certifies under penalty of law that they are not male or female (it isn't clarified in the laws I've seen what they are referring to here, but many nonbinary Germans who are not intersex can basically interpret this as meaning a gender identity which is not male or female), and (3) a medical provider informs parents are birth that an individual has medical characteristics which may be considered intersex and the parents decide if they want male, female, or diverse. Why is diverse important? Well it's one of three designations available on Electronic Health Cards (eGK) in Germany.

For ambiguous, this gets trickier. So ambiguous is a V2.X code ('A') for HL7 "administrative gender" in Germany, presented alongside "male", "female", "not differentiated", "unknown", "other", and "not applicable". I've seen it used in a few cases: (1) a known individual is registered into the system and has stated they are okay sharing a room with people of any gender, (2) a catch-all category for the diverse cases listed above, since diverse isn't in V2.X, V3, or FHIR, (3) an assignment made because parents of an intersex child cannot decide or do not want to decide (usually because the case could theoretically go either way), or (4) chimeric or mosaic genetic material. There may be other use cases as well, I'm not 100% positive.

I did write a clarifying document for some of these values in an HL7 extension document available here: https://docs.google.com/document/d/1oN4nmfylAUKB1okDildiIkW6bs1JAGyR8oAX2t1NKUw/edit?usp=sharing. (Sorry, it's a little long!)

To answer your last question, I'm really sorry, but I have to say it depends. If we follow the HL7 model of recorded gender being any gender record, then all gender assignments are recorded gender data. However, if we decide that recorded gender means that their is a concrete record outside of the EHR such as a document, then we run into trouble like the Reimer case above. I'm honestly leaning toward what we discussed in the meeting Wednesday (albeit briefly) and consider the HL7 model of these terms being overlapping.

The most common use case in EHRs today is to ask a patient "what is your assigned sex/gender at birth?" and to have the patient self-identify with any answer, without providing documentation like a birth certificate. However, jurisdictions try to incorporate documents in different ways. It's important to note that birth certificates are legal documents, not medical documents, at the end of the day. So trans and intersex people can update them in most jurisdictions and, in some cases, jurisdictions destroy the "original" birth certificate and backdate the "new" birth certificate. So if you ask a trans woman in Germany with an "F" on her birth certificate: "What is your assigned gender at birth, as it appears on your original birth certificate?" her correct answer, from a legal context, is to say "F". In the U.S., California is the only state I know of which has implemented the back-dating system, but it's being considered in other jurisdictions as well.

Sorry this is so complicated! I've spent four years researching this conundrum alone and it is not easy, especially in an international context.

Best,

Clair

EDIT 1: It is also important to note that different medical education paths, medical institutions, and legal institutions have differing definitions of and lists of intersex conditions. These usually rely on one of 3 factors: (1) is the characteristic externally visible, (2) was the characteristic present at birth (either phenotypically or genotypically), and (3) does the characteristic have any impact on sexual characteristics. Usually in the U.S. we typically say that 1 and 2 are necessary (so complete androgen insensitivity syndrome, CAIS, is not typically considered an intersex condition), but in the U.K. only 2 is typically necessary (so CAIS is considered an intersex condition). Likewise, some areas of Germany, India, and Vietnam consider early-onset puberty as an intersex condition because it (usually) fulfills criteria 2 and 3, but the condition is typically not considered intersex in the U.S. and the U.K.