Code Conformance Discussion

"Code Conformance" is related to the issues and implications for declaring "implementation expectations" for the codes specified in value sets bound to static models and datatypes. Specifically, which codes must implementers support (which codes are 'required'), and which codes are available for use if needed, but are not expected to be supported by all implementations (which codes are 'optional'). In some cases, a value-set may be composed of only "required" codes or only "optional" codes. In other cases, a value set might contain a mixture where some codes are required while others are optional. It's possible for multiple value-sets to be defined with identical sets of codes, but different constraints on which codes are required and which codes are optional.

For example, with the value set for administrativeGender, is an application compliant if it supports the code "M" and "F", but not "U". (Assuming the realm has declared a binding to the HL7 code system). At the moment the answer is not clear because it's not known whether the codes M, F and U are required or optional.

The introduction of "required" and "optional" to value sets has ramifications for constraining. If all the codes in a value set are "required", then the value-set can't be further constrained (at least not while remaining conformant to to the base specification.

• For example: If when we bind country codes at the UV level to a value set that says all codes are "required" (i.e. all implementations must support all codes to be conformant), then realm-specific constraints aren't possible. If on the other hand we bind a value set at the UV codes where the codes are optional, then we can constrain in realm bindings to a smaller set of codes, or declare some or all of them required at the realm level.

Issues are related to:

• • Are there any constraints on who can declare a value set to be "required"? Only UV or Affiliates?
    • LM: No reason for this to be any different from the ability to identify an attribute as required or optional. If it's left optional in a higher level spec, the next lower level can constrain it.
  • How would a value set definition that has required codes be expressed? A "Conformance" property with Required or Optional values, with Optional being the default?
  • Alternatively, it may be possible to indicate the expectation that all codes in a bound value set are "required" or "optional" if the value set definition itself does not have such a property, although it might be onerous to have to specify in all static model definitions. How would this alternative "conformance" expectation be expressed?
    • LM: There's an issues with this where a value-set contains a mixture of required and optional codes
  • How would a conformance statement identify that only a sub-set of the value set codes are supported? A separately registered value set bound to the static model instead of the parent binding?

--Tklein 21:20, 11 January 2009 (UTC)There are currently two (LM: three) proposals to address these concerns:

1. A binding must have a characteristic indicating if the binding must be exact, or is constrainable for conformance. IF the binding must be exact, this indicates that all of the codes in the value set, and no codes that are not in the value set, comprise the conformance set; ie no conformance statement may be asserted by any Binding Realm that is different from the specified value set. If constrainable, that means that any conformance statement that a Realm asserts on a UV binding where the value set specified has every concept in its expansion is also a member of the expansion of the value set identified in the UV constraint would be a legal and valid conformance statement. This would permit UV constraints to be developed that are large enough to encompass all value sets needed by the international community, but where any particular Realm may constrain to a proper subset of those.

2. The UV binding statement consists of an assertion of two bindings. The first is mandatory, and is a binding where no concept may be sent that is not in the specified value set; this first binding is known as the "MAX binding". The second binding is optional, and is a value set of fewer concepts than contained in the MAX value sets (but none that are not in the MAX value set); this is known as the "MIN value set". This indicates taht a conformance statement cannot be written for a value set that does not expand to contain all concepts contained within this minimum. If the MIN value set is not specified, it would mean that a value set of arbitrary restriction on the MAX could still be used for conformance statements (it would reduce to the case in (1) above).

3. Value sets are constructed with a "conformance" property included as part of their content definitions. Valuesets with identical codes but distinct "conformance" requirements are maintained as distinct value sets. Bindings are declared to the value set with the desired codes and desired conformance declaration. Two value-sets can be compared to determine whether value set A is a proper subset of value set B based on both the codes and the conformance constraint for those codes.

Any of these options would necessitate an extension to the MIF2 and binding model.

How does this relate to any work that the IC WG is doing in this area (if any)?

Discussed at Orlando WGM Monday Q2. --Tklein 23:28, 12 January 2009 (UTC) The UV binding statement consists of an assertion of one principal and two optional value sets. The principal value set (MAX) indicates the complete set of codes that are available for use (excluding CWE extensions). The remaining two value sets designate subsets of the principal value set that are:

• required (MIN) meaning they must be supported (used in some useful manner by the system) or
• IGNORED meaning they are not used in any useful manner by the system e.g. ignored.

This indicates that a conformance statement cannot be written for a value set that does not expand to contain all concepts contained within this minimum. If the MIN value set is not specified, it would mean that a value set of arbitrary restriction on the MAX could still be used for conformance statements.

The rules:

• All other bindings to that concept domain must be proper constraints where the value set represents a narrowing of the content of the value set of the UV binding.

• When you constrain you can leave the MAX the same or make it narrower,

• • you can leave the MIN the same or make it bigger.

• • you can leave the Not Supported the same or make it bigger and

• • at all times MIN and Not Supported are exclusive and must be proper subsets of MAX.

Action: The names used for min/max and not supported need review.

For further discussion with MnM.