This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "NullFlavor"

From HL7Wiki
Jump to navigation Jump to search
Line 1: Line 1:
 
{{INM Workitem}}
 
{{INM Workitem}}
 
{{MnM Open Hot Topic}}
 
{{MnM Open Hot Topic}}
 +
 +
== Update ==
 +
 +
Much of the substance of this was resolved as part of the
 +
Datatypes R2 discussion on nullFlavors. There is effectively
 +
still two outstanding issues:
 +
 +
=== Translations ===
 +
 +
because translations can have their own nullFlavor, this
 +
confuses conformance and equality reasoning. The conformance
 +
issues have largely been resolved by changes to the templates
 +
ballot. Equality is an outstanding issue. Perhaps the correct
 +
solution is to introduce more operational properties to CD
 +
that clarify how to evaluate equality in the presence of
 +
translations.
 +
 +
=== QS ===
 +
 +
Although QS is technically a nullFlavor, it's not at all clear
 +
that a PQ of QS should not be acceptable as a mandatory attribute.
 +
Is the modeling of QS right in this case?
 +
 +
== Introduction ==
 +
 
A NullFlavor (to quote the abstract data type definition) ''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. Every data element has either a proper value or it is considered NULL.'' It can be used in all attributes and data types. value. In those cases where for conformance reasons the attribute has been designated as [[Mandatory]] a NullFlavor SHALL not be used.
 
A NullFlavor (to quote the abstract data type definition) ''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. Every data element has either a proper value or it is considered NULL.'' It can be used in all attributes and data types. value. In those cases where for conformance reasons the attribute has been designated as [[Mandatory]] a NullFlavor SHALL not be used.
  

Revision as of 01:44, 2 August 2007

Update

Much of the substance of this was resolved as part of the Datatypes R2 discussion on nullFlavors. There is effectively still two outstanding issues:

Translations

because translations can have their own nullFlavor, this confuses conformance and equality reasoning. The conformance issues have largely been resolved by changes to the templates ballot. Equality is an outstanding issue. Perhaps the correct solution is to introduce more operational properties to CD that clarify how to evaluate equality in the presence of translations.

QS

Although QS is technically a nullFlavor, it's not at all clear that a PQ of QS should not be acceptable as a mandatory attribute. Is the modeling of QS right in this case?

Introduction

A NullFlavor (to quote the abstract data type definition) 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. Every data element has either a proper value or it is considered NULL. It can be used in all attributes and data types. value. In those cases where for conformance reasons the attribute has been designated as Mandatory a NullFlavor SHALL not be used.

For related pages see Datatypes R2 Issue 15, Proposal For Data Type Vocabulary Management, UML ITS Policy.

Null v. Exceptional Value

The definition of null confuses the 2 different concepts of "null" and "an exceptional value". The conflation of the 2 leads to various issues related to the nullFlavor hierarchy.

All nullFlavors should be applicable to all data types - because the definition of null and NI is type independent. Where there are datatype specific things to say, such as the concepts behind NINF, PINF, TRC, QS, and OTH, they should be managed by properties of the relevant data types themselves.

Examples

So, in regards to nullFlavor, we should not allow side effects. A side effect is where the designation of some particular element as having a particular nullFlavor causes some difference in interpretation of other sibling data, and therefore generalising the nullFlavor to NI causes different behaviour in a semantic sense.

Examples:

  • an interval with a lower bound of 5 and an upper bound of PINF means >5, while an interval with a lower bound of 5 and an upper bound of NI means, 5 - ?. So PINF assumes some special value (by convention we know that the intent is not to assert that infinity is a possible value for the upper bound)
  • QS. This is a clear example of a side effect. QS of normal saline is markedly different from NI about how much saline should be used.

In fact, the problems here are that there is invalid subsumption in the nullFlavor heirarchy. The definition of NI is: No information whatsoever can be inferred from this exceptional value.

This could subsume some code that meant that no information could be inferred, and supplied a reason. But it should be obvious from the examples above that PINF, NINF, QS, and TRC are not properly subsumed by NI. So we have a real problem here. It's not so clear whether OTH is properly subsumed by NI. Partly this depends on whether a CD with only originalText and translations is a "proper" CD or not. We could dance for many hours on the definition of this. But I think that no one would accept that two CDs with translations to the same code in the same codeSystem cannot be compared because their values are Null.