NullFlavor on II

Issue Description

In the Abstract data Types specifications generally the purpose of nullFlavour is to indicate the reason why a given data element has a NULL value. Each data type has an attribute or small group of attributes which may be considered the 'focal attributes', for example 'code' or 'value', which convey the primary value of the data type, and additionally some optional attributes which contain added information such as 'originalText'. An element would be considered to be NULL when one or more of the focal attribute(s) are NULL even though the additional attributes may still contain meaningful content.

In the II (Identifier) data type there are two possible 'focal attributes' the 'root' and the 'extension'. If the content for the root, typically an OID, is specific to an instance then it alone is required to identify the instance and no extension is required, if on the other hand the 'root' just conveys the issuer of the specific identifier then the extension contains the specific instance identifying string. For example, you could have root='Florida drivers license' and extension='specific Florida drivers license number'.

In xml both <ii root="oid" /> and <ii root="oid" extension="string" /> are valid instances depending on whether an extension is required to provide a unique instance identifier. Logically the null forms of these would be: <ii nullFlavor="nullcode" /> and <ii root="oid" nullflavor="nullcode" /> respectively. The former would indicate that you don't know or have the identifier for the instance for the reason provided, and the later would indicate that you know the value set of the identifier but that you don't have the actual value within that set. For example, <ii root="Florida drivers license" nullFlavor=UNK" /> would mean: this party has a Florida drivers license but I don't have/know the license number.

In the current xml.xsd file, a Schematron rule has been provided which says that you must either have 'root' attribute OR a 'nullFlavor' attribute but you cannot have both. This rule was created to aid in validation of ii instances. From recent examination we see that it would correctly reject invalid instances where the 'root' is the focal attribute but would falsely reject cases where the focal attribute is the 'extension'.

Proposed Disposition

In essence the rule is too tight. But given that one cannot detect when the 'root' or the 'extension' are the focal attribute at schema design time, this can only be known at model design time or later, it is not possible to craft a new Schematron rule for the XSD file which will adequately validate ii, therefore we recommend removing the current Schematron rule to avoid false rejections and advising implementers to check for the appropriate conditions in their code. This is either a change to informative content or a Technical correction to Normative specifications.