View source for P537 V2 Flavor of null

{{InM Closed Action Items}}
'''V2 Flavor of Null'''


==Sponsoring Person==
	Austin Kreisler, SAIC
== Description: ==
Add a null flavor component to all existing 2.x data types.

==JUSTIFICATION DETAIL:==
In U.S. Public Health data exchanges we will be dealing with a mix of v2.x and V3 messages/documents for the foreseeable future.  In many cases the exact same sort of data will need to be exchanged using 2.x or V3. Either we need to dumb down the V3 to preclude the use of flavors of null for data or we need to beef up 2.x to handle flavors of null.  We would much rather see the capabilities of 2.x enhanced to handle flavors of null.  2.x already has a primitive version of null flavor capability built into the CWE/CNE data types.  This proposal is to extend flavor of null capabilities to all 2.x data types that are used in fields.  To do this would require adding a new null flavor component to all existing 2.x data types.  This includes existing atomic data types.  All fields within segments would use data types with flavor of null components.  There will still need to be atomic data types without this null flavor component for use within complex data types to avoid any issues with creating too many levels of nesting in existing data types.
This proposal also included adoption of the current V3 Null Flavors vocabulary.  2.7 and V3 would share the same vocabulary.

== Open Issues ==
This proposal would probably not be backward compatible with earlier versions of 2.x since it adds a new mechanism for interpreting the meaning of any 2.x field.  In this case, it is our belief that 2.x must become forward compatible with V3 in this area to allow interoperability based upon both 2.x and V3 messages/documents.  Possible solutions to the backward compatibility issue include addition of specific rules that require implementations to declare they are V3 forward compatible vs. 2.x backward compatible.  Another option is to declare that 2.7 will not support full backward compatibility so as to allow some forward compatibility with V3 in this area.