Showing posts with label Null. Show all posts
Showing posts with label Null. Show all posts

Thursday, 9 October 2008

Null Flavors in HL7V3

The concept of null in HL7v3 is very different from HL7V2.x (See my old post on Null values in HL7V2.x. http://healthcareinformatics3000feet.blogspot.com/2007/11/null-values-in-hl7v2x.html). This is essentially to do with lack of support for optionality in HL7V3 – Reference Information Model which itself rose from the issues associated with optionality in HL7V2.x – see else where in this blog for strengths and weaknesses of HL7V2.x and HL7V3.0.
At a high level we can say that in HL7V3 the multiple exceptional values, i.e. values other than recommended or allowed by message specifications are grouped under the banner of NullFlavor. nullFlavor is a property of every data type through ‘extension.’ This property is valued and communicated as part of a message when information is missing. The flavor provides the reason why the information is missing. This can be best illustrated by the following example

The Character String with Code (SC) data type contains a character string that optionally may have a code attached. The text must always be present if a code is present. The code is often a local code.

If the name of the software(e.g. RamboRavage) is known


< softwareName> RamboRavage < /softwareName >


To indicate the name of software (RamboRavage)and code of the software(RaRv)

< softwareName code="1" codeSystem=" 2.22.222.2.222222.2.2.2.2.2222" displayName=" RamboRavage" >RaRv</softwareName>

To indicate that the software name is unknown

<softwareName nullFlavor=" UNK" />
It need to be remembered that a nullFlavor is not permitted simultaneously with a value. The various types of null flavour as per the latest HL7V3 ballot pack are given below

1.NI -no information- This is the most general and default exceptional value. There is no information which can be inferred from this exceptional value.

2.MSK- masked – This particular item has a known proper value, but it cannot be released in a given context due to security, privacy or other reasons.

3. OTH- other -There is a value, but it is not an element in the value domain of a variable
NINF negative infinity of numbers
PINF positive infinity of numbers

4.UNK- unknown - proper value is applicable, but not known.

  • ASKU - asked but unknown – information was sought from the source but not known (e.g., patient was asked but didn't know)
  • NAV temporarily not available - Information is not available at this time but it is expected that it will be available later.
  • NASK not asked - The Information was not requested from the patient
  • QS Sufficient quantity – The actual quantity is not known but sufficient enough to achieve a specific goal. For example the advice can be add sufficient quantity of water to 10 mg of medicine
  • TRC trace – The content is tool small to measure but a nonzero value

5. NA not applicable – There is no proper value for this data item for this patient; for example the date of last menstrual period is not applicable for a male.

The practical use of null can be gauged from different scenarios. For example a unconscious patient brought to the hospital have to be registered and most Patient Administration systems need at least one address. If the patient address is not known the patient address element <addr> can be set to UNK and sent to other down stream systems or repositories. If Sensitive/VIP patients need to be sent to other systems and if they do not have the same levels of security and control as the sending system have the sending system can send a null flavor of MSK indicating that they do not wish to expose the patients address.


But the usage of nullflavor has come under for huge criticism from different quarters notably from Barry Smith(Ref:http://hl7-watch.blogspot.com) where it was pointed out that the different nullflavors might lead to the need for different reasoning services and might become an overhead for message processing by applications. The other criticism of nullflavor is that the need for mandatory values for attributes would force systems to be modified to restrict users who normally ignore non-mandatory fields on screen to fill them with nullflavors. They need to be manually filled in with the real reason for that null value and proper nullflavor need to be entered on the screen. Some of the nullflavors like NAV (temporarily unavailable) are not very user intuitive terms for them to be selected. The values of +infinity and –infinity are mathematical conceptual numbers and does not indicate non-availability of data in any manner.

Organization such as CEN have rejected HL7V3 data types apart from Australia opposing the current draft ISO health data types standard (ISO 20190) based on HL7 v3 data types and one of the reasons it has been rejected or opposed is the huge confusion over usage of nullflavors(see the debate on nullflavors on openEHR website).

Friday, 30 November 2007

Null Values in HL7V2.x

In HL7V2.x the null value is indicated by ¦""¦. When a system receives this it interprets that the particular attributes value has been changed to null as the sending system has deleted the value of that particular data element in its database. It also indicates that the data element is available in the sending system’s database but currently not valued. The receiving system on receiving it should change the current value to null for that data element. However the absence of a field (¦¦) from sending system indicates that the value of the absent element may not have changed since the last event and the receiving system should retain the current value. The absence of a field (¦¦) may also indicate that the particular data element is not available in the sending system’s database.

A few tips on interpretation of "null" value and "not available" in HL7V2.x messages for application programmers

1.If the HL7 NULL value is present in message received and if the application processing allows a field to be changed to null for this source, the Interface needs to null existing application data elements.


2. If an optional non-repeating field or entire optional segment is absent in a received message, the Interface must not null the existing application values.


3. The application Interface should not support partial updates of repeating data. If some fields in a set of repeating fields are absent or null, the Application Interface may inappropriately overlay valid data or retain unwanted values. The Application Interface must not “error” the message.


4. The Application Interface must not support partial updates of repeating prioritized segments. If some segments in a set of repeating ordered segments are absent, the Application Interface may inappropriately overlay valid data or retain unwanted values. The Application Interface must not “error” the message.


5. When a message is sent the Application Interface must value all available changed and unchanged data elements in a segment


6.The Application Interface must send all instances of a repeating field.


7. The Application Interface must send all instances of repeating prioritized segments. For segments that repeat but can be uniquely identified and updated as an atomic unit, the Application Interface may send only the segment that has changed.


8.The Application Interface must send a null value for attributes that are present in the application database but have a null value. The option to send the HL7 null value need to be configurable by feed and not by field. The Application Interface must interpret zeros in a date field as null and zeros in an Application coded value field as null; however, the Application Interface must interpret zeros in a numeric field as a valid value.