Adding non-binary gender to OpenMRS


(Svitlana Honcharuk) #1

Currently OpenMRS has only male and female options when choosing gender. But we know that there can be different situations.

Adding ‘non-binary’, ‘third gender’ or ‘other’ option becomes more and more popular now. Some countries even have legalized it. According to OpenMRS Atlas, there are 9 countries where non-binary gender is legally present and where OpenMRS works. These countries include Australia, Canada, Germany, India, Nepal, Pakistan, Philippines, United Kingdom and the US. These are only ones listed on Wikipedia page.

I thought a lot about whether medical system should or should not add it. I came up with an opinion that as there are intersex people who have different combinations of sex characteristics since their birth, there should be such an option.

Seems like it’s a big thing to discuss and maybe it’s not a priority now. But as for me, this topic deserves to be raised. What do you think about it?


(Burke Mamlin) #2

It’s a good question. There can also be a distinction between physiologic gender and gender identity.

It would be easy to see OpenMRS at least adopting the four values of FHIR’s administrative gender: male, female, other, and unknown. At a minimum, any applications would be more future-proof to treat gender as an enumeration rather than boolean.


(Svitlana Honcharuk) #3

What should be the next steps for making it happen? I just feel like it’s an important thing which is worth implementing.


(Burke Mamlin) #4

There are a few challenges:

  • preventing new code that treats gender as binary instead of an enumeration
  • addressing existing code that treats gender as binary (refactor it to expect an enumeration)
  • finding other areas that treat gender as binary and address them (e.g., reports)

A couple near term steps you could take:

  • ensure the platform’s Java and REST apis work with gender "other” (this includes looking at and possibly updating javadocs)
  • write a unit test to ensure that api will always support “other” going forward

(Darius Jazayeri) #5

@lana, I appreciate that you’re taking the time to look at this, and interested in implementing it!

One other issue is probably to document more clearly what we intend for the Person.gender field to mean, and to consider whether we also need an additional field to go alongside this.

E.g. FHIR’s gender field is “administrative gender”, which I guess means “gender for book-keeping purposes”. We should probably choose a similar definition for OpenMRS

The gender may not match the biological sex as determined by genetics, or the individual’s preferred identification. Note that for both humans and particularly animals, there are other legitimate possibilities than M and F, though the vast majority of systems and contexts only support M and F.


(Aleksander Wójtowicz) #6

Great idea. Speaking of technical details about “other” gender, it would be nice if the user of the system was able to note how to address that person (implemented as a textbox popping up when selecting “other” gender and a relevant column in the DB). I know it’s just a detail, but different non-binary people may use different pronouns.


(Svitlana Honcharuk) #7

Good idea, but maybe it’d be better if we had certain options when a user chooses ‘other’. Then the system can treat this info as an enumeration instead of a string which I think is more effective.

Also, a textbox can cause a confusion sometimes because users can put invalid data there. Even if we make some validation checks, we can’t be 100% sure that the gender user has put makes sense at all.

And I’m not sure if there’s a need to go so deep. Having just ‘non-binary’ option would be enough maybe :wink:


(Darius Jazayeri) #8

@lana, I agree with the idea of finding the first incremental step, and doing this quickly to start.

A very first step could be to install the OpenMRS Reference Application, go into the database and change the gender of some demo patient to ‘O’ and then test out the application screens for that patient and note what is broken.


(Saptarshi Purkayastha) #9

What is the reason for not keeping the current database column for Person to be renamed to ‘sex’ (which means biological sex), and then creating a person attribute called Administrative Gender (or just Gender) which is of the concept type and can show from the list of answers that the dictionary defines? I have seen this being implemented in many places, and it works quite well without any code change.


(Svitlana Honcharuk) #10

The thing is that there’s also third biological sex, see Intersex people whom I’ve mentioned earlier. We need this third option anyway.


(Saptarshi Purkayastha) #11

Sorry, even though not perfect, I meant I have seen those captured using Person attributes as well.


(Darius Jazayeri) #12

@sunbiz it’s a good question. I wonder whether, in the typical existing OpenMRS deployment, the person.gender field is more likely to represent biological sex or administrative gender. Most likely it’s a poorly-defined agglomeration of both.

(Both the 1.x and 2.x Reference Applications do label this field as “gender”, not “sex”.)

My opinion is that for correctness, inclusivity, and in-line with the current data model, we should say that person.gender is administrative gender, and we should add FHIR’s additional Other and Unknown options.

I would think that for now “preferred pronoun” should be a Person Attribute (i.e. it’s up to an implementation to configure, for now).

It would make sense to have a database field as person.sex (for biological sex) and to automatically populate this with the value of person.gender (not 100% correct, but much more convenient for existing implementations). I would not want to rename the existing column though. I would rate this lower-priority than expanding the allowed values for the existing DB column.


(Daniel Kayiwa) #13

Since the gender column is already a varchar, do we need a database change at all?


(Darius Jazayeri) #14

Sorry, I misspoke in my last message. We do not need a database change to support more gender values, but we need additional application testing, and perhaps to add new options to the reference application’s registration module.