Home » Dr. Jayne » Currently Reading:

Curbside Consult with Dr. Jayne 9/21/20

September 21, 2020 Dr. Jayne 9 Comments

I’ve given up trying to count the number of healthcare organizations I’ve worked with during the last several years. Each one has had its unique challenges and fun memories.

From an organizational standpoint, though, if you’ve seen one care delivery process, you’ve seen one care delivery process. They are different. Although many things are common, each organization has different issues, and that makes healthcare IT work challenging.

Sometimes it’s a regional variation in care delivery. Hospitals on the East and West Coasts tend to be closer to the cutting edge than do some of my rural clients. Looking at a different aspect, some of my rural clients deliver amazingly coordinated care because the team is personally invested in the patients through their community connections.

I work with some organizations that are part of religious ministries, where their affiliation directly impacts the care they deliver and what can be featured in the EHR. For example, I worked with one large health system that had a contractual agreement with its patient education vendor that no family planning information could be featured in any of the monographs. Religious restriction of EHR content can be tricky when working with patient populations where sex, gender, sexual orientation, and other sensitive factors must be documented in order for the clinical team to deliver culturally competent care.

One of the issues that I’ve run across with increasing frequency is the disparity in various healthcare IT systems with regard to management of the data points around sex and gender. Some systems seem to think the terms are interchangeable, which tells me that they probably didn’t have a clinical informaticist involved in the design of their product.

I worked with one vendor that initially had a field for sex, but wanted to add one for gender. Unfortunately, in the upgrade script where the field was added, they just copied the contents of the old field into the new one, creating false assumptions about patients in thousands of practices. Needless to say, one of their clients that works closely with the LGBTQ+ population was less than amused. It took some custom work to revert the content and allow the fields to be populated as patients came in for their next visits.

This issue is often compounded when interfaces are involved. Engineers either don’t understand what the fields are used for downstream or don’t understand the negative impact of mis-mapping these data elements. Major EHR vendors vary in how they handle this information, even though it was required for certification under the 2015 EHR standards.

I still see a lot of customization in the social history portions of client EHRs as they try to meet needs unmet by the base product. Due to some of my past client engagements, I tend to have a little more expertise in this area than the average clinical informaticist, so I was glad to see an article in the Journal of the American Medical Informatics Association that documented “A rapid review of gender, sex, and sexual orientation documentation in electronic health records.”

The authors looked specifically at literature in peer-reviewed journals and identified 35 core articles that involved gender, sex, sexual orientation, and electronic health / medical records. They note that although certified EHRs must provide for documentation of sexual orientation and gender identity, users of those systems are not required to document the data. In my experience, going beyond the historical documentation of birth sex is confusing to many people, and organizations that are strapped for time and cash aren’t likely to focus educational funding on a minority group, even if they are known to be marginalized.

The core articles identified specific needs for data collection that play directly into hot technology areas, including personalized medicine. Having accurate data is important when you’re looking at therapies that may target the patient based on the genetics of their birth sex as opposed to what an observer might infer from the patient’s outward appearance. The authors give examples of why terminology is critically important, and include a table defining various terms (including birth sex, legal sex, gender, administrative gender, gender identity, and gender expression). I thought it was well done and bookmarked it as a reference for future client engagements.

The authors also provide some illustrative cases that can help in understanding why these data elements are so important in the healthcare community. Patients want to be cared for by organizations that understand their needs and meet then where they are. Their records are best managed in systems that can reflect clinical scenarios, such as a transgender man who needs breast and cervical cancer screenings. Patients may also want to opt out of providing these data elements if they don’t feel comfortable sharing that information, which may require a field to be documented as “not provided” or something similar.

I had a patient recently who walked out of a chain pharmacy, where she had gone to get a flu shot, because they asked about her sexual orientation. She felt it was none of their business because she was just there for a vaccination. In discussing her concerns, it never occurred to her that what she perceived as just a pharmacy also provides limited primary care services, where the question would have more relevance. She never thought about the fact that they were trying to be comprehensive rather than invasive, and I could tell she was really thinking about her own reaction to the question.

The article notes a couple of organizations that have been successful in managing this data, and one might not be the first one you think of. It’s not a progressive academic center or specialty center, but the US Department of Veterans Affairs. The VA took several steps, including creating a patient safety education work group, to address inconsistencies with sex-based EHR rules. The VA then developed informational sheets for patients and staff to help them understand the use of various fields in the EHR and provided training on how to have conversations with patients regarding these data elements.

This area of EHR work may seem like a small niche, but if it impacts you as a patient, it’s tremendously important. It’s an example of the challenges that makes CMIO work exciting, because you know that when you help solve these problems, it can really make a difference for the patients involved. As caregivers, we want to do the best by our patients and it’s helpful if the systems we use support us in those efforts. For those of us doing work in lesser-known realms of clinical informatics, it’s nice to see an article that lets us know we’re not alone.

Has your organization tackled the management of gender, sex, and sexual orientation documentation in the EHR? Leave a comment or email me.

Email Dr. Jayne.



HIStalk Featured Sponsors

     

Currently there are "9 comments" on this Article:

  1. I work for a large org in the south, mostly covering the areas in between urban centers. Our vendor has great offerings, and a tiny stubborn group of us scoped out a plan over two years ago. Since then it’s languished, even been declared dead a couple times before being noticed by people powerful enough to revive it but not powerful or motivated enough to actually get it moving. I get it – it’s an enormous and expensive effort for both IT and education – but it’s disheartening.

  2. HL7 has a project currently working on crafting a better understanding of how to melding current practices (that are, as you note, very problematic) with an approach that clarifies the need for both Gender Identity and what we are calling “sex for clinical use.” This project works in collaboration with the excellent work done by the Canadian authors you cite. The project information can be accessed at http://hl7.me/GHP.

  3. My organization is a healthcare technology SaaS. We’ve combatted this issue by creating custom data fields that capture information pertaining to gender, sex, and sexual orientation and preferred pronouns for our members. We also have the ability to capture preferred pronouns for all other team members (i.e., myself). Being someone in the sales department who identifies as a lesbian, I absolutely loved the fact we could capture data around high risk persons who identify as LGBTQ+. As you said, getting a system that supports our efforts in the realm of health equity for LGBTQ+ persons, or any marginalized “category” (race, ethnicity) is so important for providing culturally competent care.

  4. The team that did that rapid review is also doing great work defining sex/gender. I recommend keeping an eye out! The work should come out this year.

  5. A bit of an aside; I logically agree with you- ESPecially for rural settings. Rural patients are closer to their care givers- they go to church with them, their kids play football together…Precisely why these LGBTQ patients are far less likely to self-identify making that information far more critical.

    HOWever……boy, oh boy, I can sure see why a patient would not want that information recorded…Forget their healthcare information being hacked and sold….How about being targeted for your sexuality… getting on a “list”…..

    I know, I know, – sounds like a reach…..there was a time in the world I would’ve thought that information wasn’t dangerous. I don’t think that anymore.

    As always, insightful and provoking read, Dr Jayne!

  6. I build interfaces. It takes me about 5 minutes to setup a mapping for just about anything.
    The interface problem is that the receiving facility might allow for 4 PID:8 “Administrative Sex” values [M, F, Unknown, Other], while a sending facility might have more. A facility in California I was building an interface to had 14 – and that was 10 years ago. The Interface Engineer (me) sets up a mapping based on what project stakeholders agree to. Project stakeholders normally push for the HL7 0001 table standard {https://www.hl7.org/fhir/v2/0001/index.html}, which includes 6 values [4 + Ambiguous and Not Applicable (?)].

    Most lab results and many medications depend on age and birth sex. They do not care what you feel or how you identify. HL7 is designed to get that information to the next system.
    If I send a Positive Beta-HCG result to a medical professional with a non-binary NB indicator in PID:8, is that person pregnant, or do they have a tumor?

    A persons birth sex matters in lab results and medications. How they feel does not and could get them misdiagnosed or possibly killed if I am asked to send how they identify in PID:8.
    If HL7 wants to add an additional field for delivering how a patient feels about their gender identity, Interface Engineers will deliver it, as we do with all fields.

    • I understand where you are coming from, I just take issue with the dismissiveness of gender identity being “how they feel”. You aren’t wrong about birth mattering in some situations but also important to keep in mind that deliberate misgendering or dismissiveness of patient gender identity can present a lot of harm to a patient.

    • If a person was assigned female at birth, transitioned to male in their 20s, and has since been on hormone therapy for 25 years, then what is going to be the correct reference range for him? A 50 year old female or a 50 year old male? Using sex assigned at birth for such a patient would be very problematic and could potentially lead to the same kinds of clinical care issues you’re describing.

      Transgender patients are complex and simplifying their care to only using their sex assigned at birth is not the answer. The systems that handle their data should identify our example as a trans man so that the clinicians who have responsibility for their care have all the information they need to provide care.







Text Ads


RECENT COMMENTS

  1. "Upon learning what I do, several attendees went into some pretty serious rants about how electronic health records have destroyed…

Founding Sponsors


 

Platinum Sponsors


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Gold Sponsors


 

 

 

 

 

 

 

 

 

 

RSS Webinars

  • An error has occurred, which probably means the feed is down. Try again later.