For any binding strength other than Required, implementation of the resource with the noted binding will allow creation and exchange of resource instances that have coded content that is not included in the specified value set expansion. Conformance testing for such a binding is quite complicated and must be clarified so that IG autyhors use strengths that actually work for the use cases needed, and implementers can properly used the resource. For example when "Extensible" is used and an implementer sends a value not in the expansion, they will be communicating that the non-expansion value is to be treated as if it is in the expansion. Since this can happen in all implmentations the value set essentially becomes unbounded. I better solution would clearly indicate that the value set _ was extended _ when a member not in the known expansion is provided, for an extensable binding. When the binding is Preferred, if the member value is not in the bound value set expansion, then either the same "extended value set" clarification should be used, or a completely new value set canonical URI should be created and provided. This same approach should be used for Example bindings.

Also, guidance on when to use each of the specified strengths should be improved. For example, Preferred is the best candidate for binding when a known value set exists but the code system has restrictions (such as IP or realm--specificity) that make it occasionally not available for use, but known the less, it is the best choice if the resttrictions are not a burden.