CaBIG Flavors of Null

caBIG Flavors of Null

Introduction

Some of the code sets being considered by the caBIG VCDE working group included concept codes that didn't fit the same category as the rest of the codes. As an example, the Sex/Gender Candidate Data Standard included the code Unknown, which meant "unknown, not observed, not recorded, or refused". Rather than being a possible value representing gender, Unknown really represented a bit of metadata that:

1. indicated that a "meaningful" code was not present
2. gave a fairly generic reason why the code wasn't there

Among the disadvantages of the approach above:

• software has to be specialized to recognize the absence of information on an element-by-element basis - Unknown in gender, perhaps NA in second data element, UNK in a third.
• this approach only works with coded fields. How should some represent the fact that an address is missing because they didn't ask for it? How would they differentiate this from a missing address because the patient refused to supply it?

This gives rise to a more general question - should this type of metadata be included in individual code sets at all, or should it be generalized in a way that it could apply to any data element? The focus of the "Flavors of Null" working group is to address the following questions:

1. Should the fact that information is not supplied and the reason for its absence be treated differently from other types of information?
2. If so, how should such information be treated?

Background

Health Level Seven (HL7) has developed a possible approach and solution to this issues. The Version 3 Data Type Specification includes a both a method to test whether the value is "null" isNull which "Indicates that a value is an exceptional value, or a NULL-value. A null value means that the information does not exist, is not available or cannot be expressed in the data type's normal value set" and an additional field named "nulLFlavor" that "If a value is an exceptional value (NULL-value), this specifies in what way and why proper information is missing." The table of possible values can be found here

Discussion

Teleconferences

• March 31, 2005

Decisions

1. Flavors of null should be separate from coded values. Coded values should define "legitimate" value meanings for a data element. Nullability and nullFlavor should be defined as an attribute of any data element
2. EVS should be "robustly stocked with terms that cover the different flavors of null".
3. All of the flavors should be rooted at a single domain
   1. All data elements should be "nullable" and should have an optional(?) attribute that allows the reason for omission to be specified
   2. The data element definition process should allow the reasons for omission to be constrained (restricted) and, potentially, the "nullable" attribute to be set to false
4. These characteristics should be specified at the "composite element" or "message building" level rather than the individual element level to avoid having to provide double definitions.