HL7 makes a distinction between values that are not present and those that are null. While the meaning of `not present' is obvious (it could be paraphrased to `unknown'), the semantics of the null value remain somewhat confusing, even though the null value is repeatedly mentioned in the HL7 document.
The problem here is to get an idea of consistent general meaning of the null value, and the crucial question is:
What does a null value mean in a NM field?
the HL7 document (v2.2) tells the following (Page 2-5):
The difference [between not present and null] appears when the contents of a message will be used to update a record in a database rather than create a new one. If no value is sent, (i.e., it is omitted) the old value should remain unchanged. If the null value is sent, the old value should be changed to null.
But what does this notation of `null' mean with respect to NM or DT fields? The problem fades away, if we do regard any data transmitted by HL7 as strings. However here we want to provide a mapping from diverse data types to HL7. Should we simply map `""' to `0' then? Even though, this would solve the problems wit NM types, it would cause nonsense values in other fields like TS.
There are two ways out of this paradox:
Here we try to go the second way and assume an object, which is not present as unknown, whereas null indicates that an object is known to be non-existent or that it doesn't make sense in a certain context. This is still consistent to the interpretation of the null value concerning data bases, that is given in the HL7 standard: An unknown value will not cause the data base to be changed, but will rather be bound to what is stored in the data base.
It still remains subject to further discussion how the difference between a string of length zero and a null value would have to be represented and interpreted. For example, a null string could be encoded as `\0' (or as `""' while the null value would be `\0'). The string of length null updates a data base field to a string of length null, while a null value updates the data base to a value meaning `value does not exist'. Thus the HL7 protocol would be able to handle nulls as they are proposed for the nested universal relational database model (see LEVENE (1992)) to handle incomplete information. Since incomplete information does concern medical informatics it is strongly recommended here, to go this way of opening up the null value for a general well defined usage in any data type.
However, a problem still remains as the scope of the null value is unclear in a composite data type: If a CM field is received as being `""', what does it mean? Does it mean that the first component of the field is null and the other components are not present? Or does it mean that the whole CM data is null? This ambiguity could be solved by further interdicting the deletion of delimiters which terminate trailing items which are not present. Thus `1234^^' must not be truncated to `1234'. However the error tolerance is a feature which is relied on in the extensions of v2.2. Therefore it should be hard to convince the HL7 committee to change this. But other ways can be found (and should be found) to overcome this ambiguity.