I’m migrating a bunch of patients from an old (non-OpenMRS) EMR into an instance of OpenMRS. The existing data contains lots of blanks in the “gender” column. OpenMRS is not allowing me to save patients without gender. Is there a better alternative to just putting something arbitrary (like “U”)? Are there any problems (especially runtime errors) that one might run into with this approach?
There has been a discussion on supporting additional genders
However a quick fix would be to think about Missing instead of Unknown (as they have two different meanings)
1 Like
@mogoodrich Yes. Sorry I didn’t get the actual stacktrace, but the error was
'Patient#null' failed to validate with reason: gender: Por Favor Seleccione un Genero
(that’s “Please Select a Gender”).
@ssmusoke Good suggestion about using “Missing” rather than unknown. But that doesn’t actually address my concern, which is that OpenMRS might freak out about finding something in the “Gender” column that’s neither “M” nor “F”. Worse, maybe somewhere “Missing” would get truncated to “M” and some piece of code might see all the missing values as male. It’s that kind of undefined behavior I’m worried about.
The person validator allows you to store more than just M or F https://github.com/openmrs/openmrs-core/blob/master/api/src/test/java/org/openmrs/validator/PersonValidatorTest.java#L151
@dkayiwa Yeah, that’s right. My concern isn’t about PersonValidator, it’s about other code in OpenMRS. What unexpected side-effects might occur for patients with “U” as their gender?
I created a ticket to allow redefining the registration app config to support other gender options such as Unknown, RA-1629. The gender fields are hard-coded and not configurable together with name and address demographics sub-sections at the moment. Supporting other gender options, making the registration app as the gateway may have to require an additional config field say “genderOptions” which carries comma separated gender option characters like “M,F,U”. A character representing the gender will be saved in the end but will also be translated for views. I’m not quite sure the impact that might be caused modules as a how. I’d like to receive views on how this would be better done. Thank you.
cc: @mogoodrich, @mksd
Something to think about is that there may ultimately need to be two fields. This is something I’ve discussed in other forums.
One as “Sex” which would record the patients biological sex (Binary, M/F) and another Gender which would record the patient’s identified gender (wider range of possibilities) It may even need to differentiate identifying as a specific gender vs. actual completion of any treatments such as surgery for that transition.
Why is it important to record both? Obviously it is important to many patient’s on how they are addressed or wish to be perceived. It is also important from a medical perspective, since biological sexes are at higher risk of, or need preventive examinations for specific medical problems such as breast cancer, cervical cancer, prostate/testicular cancer etc. That risk can also change depending on where they may be in a physical transition.
It may be best to keep the current binary identification since as you mentioned it may be used in several areas of Open MRS for specific purposes, and add a gender field for tracking how a patient wishes to be identified or even where in the transition process they may be. This might be a little easier to implement rather than having to change where the current field is used?
Just something to consider as we look at how to track sex/gender in electronic health records, including preventive medicine alerts or examinations. Many are struggling with this same question.
3 Likes
Thanks @docken.
‘Unknown’ in our case is not a clinical finding, it operates in the context of strict data protection policies where a number of demographics data have to remain blank.
When a patient is unknown, so when his/her identity has to remain secret, no information about his/her sex can be keyed in. In fact it is a case where we would wish for the gender field to not be mandatory. We just do not want to provide it, full stop. But since we have to, we need a third choice.
Cc @jesplana
3 Likes
Interesting discussion! Just wanted to share this ticket https://issues.openmrs.org/browse/TRUNK-4832
And this post: Gender Type Icon next to patient info
1 Like
Would it be more appropriate to add a link to this discussion to the comments for the ticket, or just enter a comment with the above to that ticket? It would make it available when someone is able to take on the work.
Ken
It does seem in that case that it isn’t so much as unknown, as it is “not provided”, which is still different than “missing” since that would specifically be in regards to a patient transfer/data migration situation. I wonder with your case specifically @mksd if it would be better to create a “privacy screen” for patients whose identity needs remain unexposed to those other than providers directly involved in their care at that visit or encounter - since gender could effect care & treatment, especially as it relates to any built in decision support tooling.
At PIH Mexico we migrated data into OpenMRS from a legacy system. There is lots of missing data for gender. I’ve represented it with a “U” in the data (which, you’re right Jan, it ought to be “M”).
Yes adding a link to this discussion would give more context to whoever takes on the ticket. You can just click on the More button at the top, then select Link from the menu that pops up and add a Web Link.
I wasn’t able to find the “Link” from the More menu. I may not have permissions to do that in the Issue queue. I did note there is a link to a wiki article that does explain/discuss some of the above. It includes separation of gender vs sex as separate entries.
This scenario sounds more or less a data quality issue than the patient preferring an unknown gender. if that’s the case, then a kind of automated robot that could predict their gender from their historical medical records could help but this would not be a normal (M or F or U) but rather predicted (~M, ~F or ~U). Perhaps for simplicity, U would work but some patients would be offended if it appeared anywhere on their records as their gender and so it would be an inbuilt mechanism to pass the validation and move on that never interfaces in the system output. If the patient prefers Unknown, then probably they like that on their records but i agree with @docken, its; clinically important to track the actual gender in addition to the patient’s perceived or system’s unknown gender which is biologically questionable.
1 Like
Yes you did not have access to JIRA. But now you do.