Hello,
Note that HL7 V2 and HL7 V3 are very different. In the Version 3 specification, HL7 has removed the "unknown" element, leaving Male (M), Female (F) and Undifferentiated (UN). (see: http://www.hl7.org/v3ballot8/html/foundationdocuments/referencefiles/AdministrativeGender.htm) . "UN "is defined as "The gender of a person could not be uniquely defined as male or female, such as hermaphrodite." I believe that that corresponds loosely to the "Other" code in V2.
A proposed coding policy:
1) Codes that represent permissible values of a data element belong in the code set. 2) Codes that represent "metadata" about the data element - specifically the fact that there no value is specified or the value doesn't fit the data type or permissible values of the data element should NOT be part of the code set.
Exceptions: 1) Codes that represent "none of the above" or "not elsewhere classified" should not be part of a code set. The reason behind this is that the meaning of "NEC" will change as codes are added to the set. As an example, suppose you had a field that allowed you to specify, say, shoe color. If you designed a code system that had "Brown", "Black" "White" and "Color, NEC", Red shoes would be recorded as NEC. If, at a later date, you added "Red" to the basic set of colors, the meaning of "NEC" would change. People wouldn't be able to understand what had already been coded with knowing whether it was the "pre-Red" or "post-Red" NEC.
2) Code sets that are mandated by external agencies require special handling. HL7 has been grappling with this issue - what do you do if, say, the CDC states that shoe colors will be reported as "Red, Brown, Black, NEC and Unknown"? One solution would be to have a different set of codes externally vs. for external reports, but sometimes that can be an issue...
I think that the mapping issue is going to exist no matter how the "flavors of null" matter is resolved. As the examples below show, even something as apparently "simple" as gender doesn't necessarily have a 1-1 mapping. While HL7 V2 "O" clearly maps to the CDC "9", where does the "U" go? I think that we are going to find that it will be the exception rather than the rule that there will be an exact 1-1 mapping between codes from different agencies or coding bodies. The trick is either to (a) select the one that most closely approximates the intended use of the data element or (b) if none comes close, create a new set that matches what we need. I think that this issue may well be worth some additional discussion, just to be certain that everyone understands the implications (and non-implications) of the caBIG selection of a code set.
Harold Solbrig
From: Brian Davis [1] Sent: Wednesday, April 06, 2005 11:43 AM To: Solbrig, Harold R. Cc: klinglerk@saic-solutions.com; keller_michael@bah.com; lynne@crch.hawaii.edu Subject: FW: caBIG- VCDE WS - question for Flavors of Null group
Hi Harold,
I have a question from the Sex & Gender small group: will you be considering the value domain of "other" as a flavor of null? (Lynne Wilkens, copied, is leading that group, and Kim Klingler, is also serving on both groups) They would like to know whether you will be addressing this value domain in your discussions. The advantage of leaving out "other" is to avoid ambiguous terms, but the disadvantage is that mapping between data elements might be comprimised.
See specific examples of "other" in the following Sex&Gender data elemets proposed by other standard bodies:
CDC (v2.4 Appendix A) X 0-Not Known 1-Male 2-Female 9-Not Specified, Unknown, Not Stated, Unsexable, Transsexual, Other
HL7 (v2/2.31) PV1 and PID Segments X F-Female M-Male O-Other U-Unknown
Please let Lynne and Kim know by tomorrow whether you feel this is part of the Flavors of Null deliberation.
Thanks.
Brian
