Question: v2 optionality

Dec 17, 2013

Question

I am confused by the HL7 V2.7 specification documentation “V27_CH02_Control “ around optionality definition. A data element can have three population states {Not populated.,Null,Populated,}

R represents “required”; if a data element is defined with “R”, could I represent it with   in the instance or always like something ?    
RE represents “required but may be empty”.  If data element is defined with “RE”, I can represent it with ”” in the instance and like   and something ?

Answer

Firstly, clarifications. A field can have 3 states:

  • Populated. The sending system sends a value in the field, e.g.  1234567^^^MR^KP-CA
  • Not Populated: The sending system does not supply a value for the field, i.e.  
  • Null: Any existing value for the corresponding data base element in the receiving application should be deleted, i.e. ””
Before I go on, a couple of comments about the business of null. The definition is implicitly transactional - it says nothing about what it means for a field to be “null”, only that it’s an instruction to delete any data you have. Logically, then, a field ”” should only be used in a message stream where the transactional context is known - in other words, the sending system knows what it means to “delete” the data, and why it is saying to do so. However it’s common in practice for systems to send ”” outside that context, to try and actually mean something. Because the definition doesn’t say anything about it means, there’s a wide variation of views on how to interpret this, and it’s a fruitful area for non-interoperability (I suppose you could blame the spec for this, but people are not conforming when they use ”” outside a narrow context).

With regard to conformance, this table summarises how conformance and state interact:

Code Description Populated ( xx ) Not populated (   ) Null ( ”” )
R Required Yes Not allowed Not allowed            
RE Required but may be empty Yes Yes, provided conditions are met Yes, provided conditions are met            
O Optional Yes Yes Yes            
C Conditional Yes, provided conditions are met Yes, provided conditions are met Yes, provided conditions are met            
X Not used with this trigger event Not allowed Not allowed Not allowed            
B Backwards Compability Depends on notes Depends on notes Depends on notes            
W Withdrawn No Yes No            
The rules for not populated and null are exactly the same because null is an implicit statement that the field is not populated, and for the receiver to remove previous data. From a conformance point of view, then, it’s no different - and a system that sends ”” in order to not send an empty field is using the field completely wrongly.

Note that R and RE have implications for the way applications behave beyond just the implications for what can be in the instance.