Wednesday, December 01, 2010

Demographics: HL7 vs. Reality. Part 2 – Gender

(The second in a series of posts by William Hogan)

In my last post I showed, on the basis of the example of marital status, how standardization of demographic information is challenging and how typical information-modeling techniques fail to help the problem.

In this post, I show how HL7 handles gender. Again, we will see difficulties for standardization. Additionally, we will see resultant hindrances to informatics support of humane, competent patient care.

First, we must review how the HL7 Reference Information Model (RIM) structures demographic information.  It does so primarily by structuring the information as “attributes” of key “classes”, including LivingSubject, Person, and NonPersonLiving-Subject. The latter two classes, according to HL7, “specialize” the LivingSubject class.

The HL7 definitions of these classes are relevant to our understanding of gender, so I reproduce them here.

LivingSubject: An organism, alive or not.

Person: A human being.

NonPersonLivingSubject: A subtype of LivingSubject that includes all living things except the species homo sapiens.

Next, we need to note that the RIM represents gender as the administrativeGenderCode “attribute” of the LivingSubject “class”. We also need to review the HL7 definition of this “attribute”:
The gender (i.e., the behavioral, cultural, or psychological traits typically associated with one sex) of a living subject as defined for administrative purposes. 
We are then told of just one such administrative purpose: … the appropriate allocation of inpatient bed assignment.

Problem #1
First, a minor problem. Note that administrativeGenderCode is applicable to all organisms (LivingSubjects), not just human beings.  However, the only administrative use case we are given for this attribute is hospital bed assignment, something relevant only to humans.  Even if veterinary hospitals assigned “inpatient beds” to animals (as opposed to cages or pens), placing two animals in the same enclosure is the exception not the rule.

Which raises yet another problem. 

Problem #2
For humans, single rooms now, too, have become the rule and not the exception, at least in the United States. With the only stated use case for this “attribute” fast becoming a relic of the past, should it remain? I am also struggling to imagine other, non-clinical, administrative uses for administrativeGenderCode. 

But larger, much more relevant and important issues loom. 

Problem #3
What are we to do for recording gender for “non-administrative” purposes, such as patient care? We are told in the notes for administrativeGenderCode that:

This attribute does not include terms related to clinical gender. Gender is a complex physiological, genetic, and sociological concept that requires multiple observations in order to be comprehensively described.

Thus we find out that, even for humans, the administrative-GenderCode “attribute” is not relevant for recording someone’s true gender!  Why not instead call the attribute “bed assignment instruction” (or bedAssignmentInstructionCode), and have values “male bed” and “female bed”?

Here, HL7 has essentially recommended to us more than one way of recording a patient’s gender, with obvious implications for interoperability (more than one way to record something is always a risk to interoperability). 

And how are we to record “clinical gender”?  The RIM does not tell us (not here, anyway).  It is not an “attribute” of a “class”, so presumably we must record it as an “Observation”, a different “class” in the RIM.  But then we are allowed to record gender in any of the following non-interoperable ways, even when using HL7 and standard terminologies (with thanks to this document):

Obs.code
Code description
Code terminology
Obs.value
Value code description
Value code terminology
263495000
gender (observable entity)
SNOMED CT
248153007
male (finding)
SNOMED CT
365873007
gender finding
SNOMED CT
248153007
male (finding)
SNOMED CT
248153007
male (finding)
SNOMED CT
---*
---
---
---*
---
---
248153007
male (finding)
SNOMED CT
21840-4
Gender
LOINC
248153007
male (finding)
SNOMED CT
* The value in these cases is simply omitted, as opposed to being populated with one of HL7’s “flavors of null”.

Problem #4
But there is something wrong with my table above. The SNOMED CT code for “male (finding)” above is for the sex, not the gender of the individual. I was forced to use it because SNOMED CT provides no codes for male or female gender (although it does provide codes for “unknown gender” and “gender unspecified”).  The code for “male” that I used in the table is a child of “finding related to biological sex”.

The World Health Organization explains sex and gender as follows :
“Sex” refers to the biological and physiological characteristics that define men and women. “Gender” refers to the socially constructed roles, behaviours, activities, and attributes that a given society considers appropriate for men and women.
To put it another way:
“Male” and “female” are sex categories, while “masculine” and “feminine” are gender categories.
We can further distinguish, at a minimum, phenotypic vs. genotypic sex, where the former refers to one’s gross anatomy and the latter refers to the configuration of sex chromosomes in one’s cells (XX vs. XY vs. anomalous configurations). It is possible to have female genitalia but a genotype of XY, for example, due to androgen insensitivity syndrome. Thus the distinction is real and worth making in EHRs. It will certainly be important for interoperability of data generated by chromosomal analyses.

In addition to SNOMED, both HL7 and LOINC also confuse gender and sex. For one, in previous versions of its standards (including the RIM), HL7 referred to this attribute as “administrative sex”. Furthermore, the HL7 NonPersonLivingSubject “class” has an attribute called genderStatusCode, defined as: The state of the primary reproductive organs of a non-person living subject. But of course, the state of an animal’s reproductive organs (and I am not really sure what this means, are they talking about spayed and neutered pets, for example?) has to do with its sex, not its gender. Recall that HL7 defines gender as …behavioral, cultural, or psychological traits typically associated with one sex.

LOINC has codes labeled “gender” for the sex of a baby as observed on ultrasound. It would be difficult indeed to elucidate, even by ultrasound, the “behavioral, cultural, or psychological traits typically associated with one sex” of a fetus. Codes 11882-8 and 11883-6 both have gender as the attribute measured  by ultrasound (the “component” in LOINC-speak) but have a “related name” of ‘fetal sex’.

Problem #5
Now, some may say that the distinction does not really matter for “all practical purposes”. And true, in practice, it is only the administrativeGenderCode that gets collected and included as structured data in the EHR, claims submissions, hospital discharge data sets, and so on.
  
But this is a problem and not a virtue. For many practical purposes, it leads to great confusion and causes problems that physicians take seriously. For example, there was a recent listserv discussion of the Association of Medical Directors of Information Systems on gender vs. sex and how it applies to transgendered and transsexual individuals.  One physician describes the following real-world, practical, scenario:
I don’t think there is a clear standard [with respect to representing sex and gender]. For what it is worth, I have a long term patient who went through this, male to female. There is a non ICD diagnosis in [our EMR system] (which I think you use) that I put on the problem list saying “History of  sex reassignment male to female.” In registration system gender is as female, but we have discussed that we might need to change that back to male for medical coverage of some conditions in the future or face non coverage and higher [self] pay. 
Like most, our preventive reminders aren’t sophisticated enough to pick up the unique issues here, so Pap smears are manually permanently deferred on this patient. 
Our organization takes the view that we enter the gender race and ethnicity that you say you are.
So our state-of-the-art EHRs cannot even represent sex vs. gender, let alone reason appropriately with the data or exchange sex and gender data in an interoperable way. And HL7 and related terminology standards offer us no assistance, and even hinder us, in this regard.

With the net effect that our entire healthcare information system is really using an attribute—intended only for gender-specific bed assignment, an increasingly irrelevant task—for patient care, setting health care policy, and numerous other secondary uses of “administrative-but-forced-on-physicians-and-patients-as-clinical-at-least-in-part-because-IT-vendors-and-IT-departments-and-standards-organizations-cannot-figure-out-sex-vs-gender” data.

Monday, November 22, 2010

Demographics: HL7 vs. Reality. Part 1 – Marital Status

(First in a series on HL7 and Demographics from Bill Hogan.)

When it comes to demographic information, the conventional wisdom is that things like gender, race, marital status, birth date, etc. are fairly simple things to represent and collect. It should, then, be of little trouble to standardize demographic information, especially since demographic data have broad usage and applicability beyond just health care.

Unfortunately, the conventional wisdom is wrong. Like so much other data, demographic data are rarely standardized. A failure to account for what it is on the side of reality that we wish to capture in an information system plays an important role in creating this situation.

A brief review of the HL7 experience in harmonizing standards for demographic data as well as how the HL7 RIM handles demographic data, is illustrative. In this post, we consider marital status.

First, an HL7 effort to harmonize marital status codes with other standards development organizations (SDOs) has encountered problems, such as other SDOs going out of business, intellectual property issues, specifying which SDO will “own” and “maintain” various sets of code values, new suggestions for other standards for the task, and re-opening of discussions about the status of particular codes, their “meaning”, and their appropriateness for inclusion (see thread below). The ultimate status of the harmonization effort is that HL7 never formally adopted the harmonized codes for marital status. It appears that the Health Information Technology Standards Panel (HITSP) did adopt them prior to going out of business. It seems that no other standards organization has adopted them. What follows is from the HL7 Vocabulary Working Group listserv and highlights the issues (the context is supplied below):
Originally the plan was to have HITSP be the maintainer of this value set, but obviously that is not possible now with the ending of the funding for HITSP...
On the X12 side of the ledger, I have started to do the Data Maintenance to get the HITSP approved value set referenced in the X12 standard. The hold up for that is the need for X12 to know the maintaining organization…
It would not be good to have HL7 making changes to fit its implementation and that be different than the value set that gets recognized as the standard used by X12.
With respect to how the RIM represents marital status, first we note that HL7 places most demographic information as “attributes” (in HL7 lingo) of two classes: LivingSubject and Person. Note that the latter specializes the former. 

LivingSubject “attributes”
administrativeGenderCode
birthTime
deceasedInd
deceasedTime
Person “attributes”
raceCode
ethnicGroupCode
maritalStatusCode

So, marital status is an “attribute” of the Person class. Note that the Person class, per the RIM, may be used to represent a group of people as well as a single person. What the marital status of a group of people might represent is not clear.

HL7 volunteers worked diligently to create a “harmonized” value set for the marital status “attribute”. In HL7, a “value set” is essentially a collection of codes that may serve as the value of an “attribute” of a “class” in the RIM. The harmonized value set, which draws marital status codes from SNOMED CT, is as follows:


SNOMED CT Code
SNOMED CT Fully Specified Name
125725006
Single, never married (finding)
20295000
Divorced (finding)
2326000
Marriage annulment (finding)
3353000
widowed (finding)
87915002
Married (finding)
13184001
Separated (finding)
430617007
Legaly Separated with Interlocutory Decree (finding)
22187004
polygamous (finding)
430618002
Domestic partnership (finding)
408821002
Lives with partner
So, what is wrong with this set of codes? Well, in reality, either one is married or not. Thus there are only two statuses. The remainder of the information has nothing to do with one’s marital status per se, but also includes information about one’s marital history and living arrangements. For example, if you are divorced, then your marital status is “not married”, but it so happens that your most recent marriage ended by legal dissolution. Similarly, if you are widowed, then you are “not married”, but your most recent marriage ended with the passing of your spouse. Living arrangements also come into play in “separated”, which means “married” but “living apart”. Note that a legal separation (which does not necessarily imply “living apart” – see the movie War of the Roses) requires a different code. 

Capturing various subsets of the combinatorics of status plus history plus living arrangements plus etc. is what causes such divergence and diversity (and thus non-standardization). SNOMED CT, from which the value set was drawn, includes numerous other, interesting, and active-for-clinical-use “marital statuses” such as “Spinster”, “Eloped”, “Newlywed”, and “Cohabitee left home”.

Of course, we do not deny the need for ease of data entry. Yes, picking “divorced” from a list is easier than picking “not married” from one list and then picking “most recent marriage ended with legal dissolution” from another list. 

Also, we do not deny the need for parsimonious display of information. “Divorced” can communicate the information needed quite efficiently (assuming that there is a use case for “divorced” vs. “widowed” vs. “annulled”).

However, parsimony in data entry and display does not mandate parsimony in representation. Furthermore, representational shortcuts that combine information about multiple entities in reality, as with these marital status codes, frustrate interoperability  an outcome which HL7 and other SDOs are presumably trying to avoid.





HL7 Vocabulary Working Group Thread on Marital Status
Whatever happened to the new marital status codes?



Sat, Aug 28, 2010 at 6:39 PM
Reply-To: tom@nova-pro.nl
To: vocab@lists.hl7.org
Hello vocab gurus,

A while ago (must be 2 years by now) I was part of a group that spent quite a bit of time coming up with a new and improved code system for marital status codes. This resulted (as far as I know) in a list that everyone involved was quite content with). To my amazement, when I looked up marital status in the current HL7 vocabulary, I found the same old codes there were before. What happened to the new set?

Thanks,
Tom



Cecil Lynch
Sat, Aug 28, 2010 at 7:48 PM
Reply-To: Cecil Lynch
To: tom@nova-pro.nl, vocab@lists.hl7.org
I remember that well and Bob Davis had the lead on it and I submitted the additonal SNOMED codes to round out the set.

Cecil


Kevin Coonan
Sun, Aug 29, 2010 at 9:04 AM
Reply-To: Kevin Coonan
To: Cecil Lynch
Cc: vocab@lists.hl7.org, tom@nova-pro.nl
I think one of the codes got caught fooling arround with one of the ActRelationshipType codes and they split up. 



Bob Dolin
Sun, Aug 29, 2010 at 12:04 PM
Reply-To: Bob Dolin
To: Cecil Lynch
Cc: tom@nova-pro.nl, vocab@lists.hl7.org, Robert Davis
Greetings,

Attached is the set the Bob Davis developed (see section 4.1). I believe all the requested SNOMED codes were created, and are included here.

Take care,
Bob


HITSP Foundations Harmonization Notice Jun_090526-2.doc
163K


Ted Klein
Sun, Aug 29, 2010 at 5:32 PM
Reply-To: Ted Klein
To: Bob Dolin , Cecil Lynch
Cc: tom@nova-pro.nl, vocab@lists.hl7.org, Robert Davis
Thanks for posting this, Bob.

I don't ever recall seeing this material submitted to Harmonization, which is the only mechanism to get vocabulary updates into HL7 vocabulary.
The values that ARE in the v3 vocabulary are the most recent ones submitted by Bob Davis some years ago for Marital Status. Note that this is the Code System. The only Value Set in the HL7 published vocabulary built on this code system, also named 'MaritalStatus', contains all of the codes in the Code System, plus something odd apparently pulled in from UB92. I suspect this is some historical artifact, and represents an error that needs to be cleaned up. Or it might have been inserted in an attempt to cover the situation where local statue requires the codes in the UB92 form locator 16 to be used. Someone needs to examine this.

I note that the HITSP document does not list one of the concept from Bob's set, Interlocutory. And one of the concepts in your set, Separated (as distinct from Legally Separated), does not exist in the HL7 set. I recall some of the discussions in Vocab on these two, and am curious about the differences, since Vocab and Harmonization ended up agreeing with the set that is in the V3 vocabulary as of right now after quite compelling discussion about Interlocutory and the issues around some kind of 'separation' that is not 'legal separation' but is somehow distinct from 'married' as required for the data entry and processing. I can't recall all the discussions now.

If you want a Value Set added to the V3 vocabulary store, it MUST come through the Harmonization process, using a Vocabulary Facilitator. I know that there have been some challenges in the last two years with vocabulary facilitators in structured documents. I don't know how you intended for this to come through. But I've never seen this SNOMED value set ever show up.

Let me know.

-Ted


Orvis, Nancy, CIV, OASD(HA)/TMA
Mon, Aug 30, 2010 at 7:31 AM
Reply-To: "Orvis, Nancy, CIV, OASD(HA)/TMA"
To: clynch@surewest.net, tom@nova-pro.nl, vocab@lists.hl7.org, Gregg.Seppala@med.va.gov
Greg Seppala, did this get changed or harmonized at HITSP or with the SCO (Stds Coord Org)?
Nancy Orvis


Gregg Seppala
Mon, Aug 30, 2010 at 8:53 AM
Reply-To: Gregg Seppala
To: "Orvis, Nancy, CIV, OASD(HA)/TMA"
Cc: clynch@surewest.net, tom@nova-pro.nl, vocab@lists.hl7.org, Gregg.Seppala@med.va.gov
Nancy,
The value set was recommended by HITSP Foundations, accepted by the SDO's, approved by the Panel. That is where the cracks start showing up -- I am not aware of any firm process for updating HITSP constructs to reference the approved value set and adoption by SDO's was left to each SDO. I think the SDO's agreed to at least map their existing values to the value set some day.

Gregg Seppala
Patient Administration WG Co-chair


Orvis, Nancy, CIV, OASD(HA)/TMA
Mon, Aug 30, 2010 at 9:30 AM
Reply-To: "Orvis, Nancy, CIV, OASD(HA)/TMA"
To: Gregg Seppala
Cc: clynch@surewest.net, tom@nova-pro.nl, vocab@lists.hl7.org, Gregg Seppala
So Gregg, can't we initiate HL7 adoption via PA or vocab committee/org ballots and have the submitters be the HL7 reps that worked with HITSP and SCO (e.g. you and John Quinn)? To me, as the DoD Member of HIT Stds committee and the DoD lead on Federal Health Architecture, and a federal agency observer at the Sco, HL7 should take those specs back and incorporate for discussion as to whether HL7 wishes to change its internal vocabularies, change the vocab for the US domain, or have a mapping. I believe this is important to address this year starting this September. Any agreement or other thoughts?

Nancy J. Orvis, M.H.A, CPHIMS
Dir Health Stds Participation & IM/IT Integration
Office of Information Management
DoD(HA)/TMA


Gregg Seppala
Mon, Aug 30, 2010 at 10:57 AM
Reply-To: Gregg Seppala
To: "Orvis, Nancy, CIV, OASD(HA)/TMA"
Cc: clynch@surewest.net, tom@nova-pro.nl, vocab@lists.hl7.org, Gregg Seppala
Nancy,
Since Plan A (Bob Davis working with Vocabulary work group who approved the change) did not work then submitting a harmonization proposal from Patient Administration would be a reasonable Plan B. I can add it to the agenda for Cambridge to seek PA endorsement.



Orvis, Nancy, CIV, OASD(HA)/TMA
Mon, Aug 30, 2010 at 12:03 PM
Reply-To: "Orvis, Nancy, CIV, OASD(HA)/TMA"
To: Gregg Seppala
Cc: clynch@surewest.net, tom@nova-pro.nl, vocab@lists.hl7.org, Gregg Seppala
I can support that.
Nancy J. Orvis, M.H.A, CPHIMS


W.Ted Klein
Mon, Aug 30, 2010 at 6:21 PM
Reply-To: "W.Ted Klein"
To: Gregg Seppala , "Orvis, Nancy, CIV, OASD(HA)/TMA"
Cc: clynch@surewest.net, tom@nova-pro.nl, vocab@lists.hl7.org, Gregg Seppala
One nit that we still need to get run to ground: I am still waiting for a resolution from NLM on the IP issues surrounding publishing SNOMED Concept Identifiers in the HL7 Vocabulary, in Value Sets that are added to HL7 by HL7 members. The issue is that the vocabulary is published internationally to all HL7 member affiliates, and many of them are not SNOMED licensees. I have had some conversations with NLM on this and we are working towards a solution, but we are not there yet. Hopefully we'll have an update on this in Cambridge.
-Ted


Lloyd McKenzie
Mon, Aug 30, 2010 at 7:42 PM
Reply-To: Lloyd McKenzie
To: "W.Ted Klein"
Concept ids with no display names aren't terribly useful . . .  And if the SNOMED codes are nicely structured, we should be able to define the value set by only referencing a single concept id.
Lloyd McKenzie


W.Ted Klein
Mon, Aug 30, 2010 at 8:57 PM
Reply-To: "W.Ted Klein"
To: Lloyd McKenzie

That is exactly what the discussion with NLM is all about. The current 'not terribly useful' format is the only one that we are certain will not violate IP restrictions. So that is what we are stuck with until we get clarification.
-Ted


Case, James (NIH/NLM) [E]
Tue, Aug 31, 2010 at 8:29 AM
Reply-To: "Case, James (NIH/NLM) [E]"
To: Lloyd McKenzie , "W.Ted Klein"

I took a look at the new hierarchy and unfortunately found some issues with it that relate more to the internal structure of SNOMED CT than to content coverage, but suffice to say that all of the concepts needed are under a single parent, so as Lloyd suggests, the value set can be defined by referencing a single concept ID.

Jim

James T. Case MS, DVM, PhD
Health Program Specialist, SNOMED CT
National Library of Medicine/NIH


rdavis@nahdo.org
Tue, Aug 31, 2010 at 9:35 AM
Reply-To: rdavis@nahdo.org
To: "Case, James (NIH/NLM) [E]"

Hi All,

I am sorry I was away yesterday to not weigh in on this discussion.   Lots of history here.   The list of concepts that was ultimately approved as a HITSP standards was originally created with a joint HL7 and X12 harmonization project.  The key HL7 group was Vocabulary of which I have lots of thanks but a particular shout out to Ted and Cecil.   That list of concepts was taken to HITSP and they gave their seal of approval on the work done by the joint HL7 and X12 work groups.

Originally the plan was to have HITSP be the maintainer of this value set, but obviously that is not possible now with the ending of the funding for HITSP.  I had a conversation with Jim Case soon after HITSP ceased to exist.  My concern then and persists today is who will be the maintainer / keeper of the data set.  Since we want multiple SDO's to implement the HITSP approved standard, I believe we need to have a central authority determine the standards that will apply to health transactions.  That is the conversation that I started with Jim.

On the X12 side of the ledger, I have started to do the Data Maintenance to get the HITSP approved value set referenced in the X12 standard.  The hold up for that is the need for X12 to know the maintaining organization.  To me that is the void left by not having a HITSP or some other entity to be a recognized central authority.

I would assume that much of this tread of discussion is about HL7's implementation of the HITSP Marital Status recommended standard.   If that discussion leads to the need to make changes then it expedites the need to find a maintainer recognized by all the SDO's.  It would not be good to have HL7 making changes to fit its implementation and that be different than the value set that gets recognized as the standard used by X12.


Bob Davis
518-456-1735



W.Ted Klein
Tue, Aug 31, 2010 at 9:40 AM
Reply-To: "W.Ted Klein"
To: rdavis@nahdo.org, "Case, James (NIH/NLM) [E]"
Cc: Lloyd McKenzie , Gregg Seppala , "Orvis, Nancy, CIV, OASD(HA)/TMA" , clynch , tom , vocab , Gregg Seppala , Don Bechtel , Bob Dolin
Nice summary of the history, Bob.  Thanks!

That still leaves the question as to whether the final set is to use the HL7 codes, or the SNOMED equivalents that were developed, and still leaves the issue of whether or not the semantic between the HL7 concept for 'interlocutory' and the SNOMED 'separated' are identical or not. And if, as Nancy suggests, a mapping is to be maintained between the two of them, where should such a thing be housed?  (HL7 does not persist nor distribute mappings at this time).

-Ted



Case, James (NIH/NLM) [E]
Tue, Aug 31, 2010 at 10:28 AM
Reply-To: "Case, James (NIH/NLM) [E]"
To: "W.Ted Klein" , "rdavis@nahdo.org"

Just from a definitional standpoint, I think that the semantics between "interlocutory" and "separated" are sufficiently different from each other that they should not be cross mapped.  In thinking about it, I don't really think that Interlocutory belongs in the value set at all as it defines the procedural process rather than the marital status.

I think Bob's point about the maintenance authority is an essential one to resolve as well.

Jim
James T. Case MS, DVM, PhD
Health Program Specialist, SNOMED CT



Bron Kisler
Tue, Aug 31, 2010 at 12:10 PM
Reply-To: Bron Kisler
To: "Case, James (NIH/NLM) [E]"

Ted et al,

CDISC also worked on harmonizing with the HITSP recommendation for Marital Status. It seems like there was only a difference in 1-term, but I don't know if the final HITSP recommendation was made / implemented. We have Marital Status terms coded in NCI Thesaurus that are open and free for anyone to use in the world. Below are the terms we have. If we need to add something, we will be glad to in order to be harmonized with HL7 and accommodate your needs. Let me know if this is a solution you would be interested in.

See you tomorrow in DC -- Bron

Annulled
Divorced
Interlocutory
Separated
Married
Never Married
Widowed
Polygamous
Domestic Partnership