|
|
| Line 2: |
Line 2: |
| | | | |
| | === Introduction === | | === 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: | + | 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, "unkon |
| − | | |
| − | # indicated that a "meaningful" code was not present
| |
| − | # 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:
| |
| − | # Should the fact that information is not supplied and the reason for its absence be treated differently from other types of information?
| |
| − | # If so, how should such information be treated?
| |
| − | | |
| − | === Background ===
| |
| − | Health Level Seven (HL7) has developed a possible approach and solution to this issues. The [http://www.hl7.org/v3ballot8/html/foundationdocuments/helpfiles/datatypes.htm Version 3 Data Type Specification] includes a both a method to test whether the value is "null" [http://www.hl7.org/v3ballot8/html/foundationdocuments/helpfiles/datatypes.htm#prop-ANY.isNull 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 [http://www.hl7.org/v3ballot8/html/foundationdocuments/helpfiles/datatypes.htm//#domain-NullFlavor here]
| |
| − | | |
| − | | |
| − | === Discussion ===
| |
| − | ==== Teleconferences ====
| |
| − | * [[March 31, 2005]]
| |
| − | | |
| − | | |
| − | === Decisions ===
| |
| − | # 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
| |
| − | # EVS should be "robustly stocked with terms that cover the different flavors of null".
| |
| − | | |
| − | ** All of the flavors should be rooted at a single domain
| |
| − | # All data elements should be "nullable" and should have an optional(?) attribute that allows the reason for omission to be specified
| |
| − | # 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
| |
| − | | |
| − | ** 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.
| |
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, "unkon
