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 | ||
|
Cecil Lynch | Sat, Aug 28, 2010 at 7:48 PM | |
Reply-To: Cecil Lynch To: tom@nova-pro.nl, vocab@lists.hl7.org | ||
|
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 | ||
|
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 | ||||||
|
Ted Klein | Sun, Aug 29, 2010 at 5:32 PM | |
Reply-To: Ted Klein To: Bob Dolin Cc: tom@nova-pro.nl, vocab@lists.hl7.org, Robert Davis | ||
|
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 | ||
|
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 | ||
|
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 | ||
|
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 | ||
|
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 | ||
|
W.Ted Klein | Mon, Aug 30, 2010 at 6:21 PM | |
Reply-To: "W.Ted Klein" To: Gregg Seppala Cc: clynch@surewest.net, tom@nova-pro.nl, vocab@lists.hl7.org, Gregg Seppala | ||
|
Lloyd McKenzie | Mon, Aug 30, 2010 at 7:42 PM | |
Reply-To: Lloyd McKenzie To: "W.Ted Klein" | ||
|
W.Ted Klein | Mon, Aug 30, 2010 at 8:57 PM | |
Reply-To: "W.Ted Klein" To: Lloyd McKenzie | ||
|
Case, James (NIH/NLM) [E] | Tue, Aug 31, 2010 at 8:29 AM | |
Reply-To: "Case, James (NIH/NLM) [E]" To: Lloyd McKenzie | ||
|
rdavis@nahdo.org | Tue, Aug 31, 2010 at 9:35 AM | |
Reply-To: rdavis@nahdo.org To: "Case, James (NIH/NLM) [E]" | ||
|
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 | ||
|
Case, James (NIH/NLM) [E] | Tue, Aug 31, 2010 at 10:28 AM | |
Reply-To: "Case, James (NIH/NLM) [E]" To: "W.Ted Klein" | ||
|
Bron Kisler | Tue, Aug 31, 2010 at 12:10 PM | ||||||||||
Reply-To: Bron Kisler To: "Case, James (NIH/NLM) [E]" | |||||||||||
|