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

(also available here:

http://publicaa.ansi.org/sites/apdl/Documents/Forms/DispForm.aspx?ID=65633&Source=http%3A%2F%2Fpublicaa%2Eansi%2Eorg%2Fsites%2Fapdl%2FDocuments%2FForms%2FAllItems%2Easpx%3FRootFolder%3D%252fsites%252fapdl%252fDocuments%252fStandards%2520Activities%252fHealthcare%2520Informatics%2520Technology%2520Standards%2520Panel%252fStandardization%2520Committees%252fFoundations%252fUp%2520for%2520Panel%2520Approval%26View%3D%257b21C60355%252dAB17%252d4CD7%252dA090%252dBABEEC5D7C60%257d&RootFolder=%2fsites%2fapdl%2fDocuments%2fStandards%20Activities%2fHealthcare%20Informatics%20Technology%20Standards%20Panel%2fStandardization%20Committees%2fFoundations%2fUp%20for%20Panel%20Approval

Note that the spelling mistakes are the fault not of SNOMED CT, but of whomever transcribed the codes into the set.)

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

---