Allow mapping to terminology for DV_Boolean

@Diego - we have actually done exactly that in some case but where the value is definitely boolean or worse still where the allowed value is only one boolean state, it is confusing for devs and reviewers to see the DV_CODED_TEXT construct. The more we can make this sort of issue self documenting the better uptake we will have.

Why don't go all the way and use an alternative of DV_CODED_TEXT to model these instead of using boolean? I'm pretty sure that a binding would be more meaningful than any 'true/false' (which depending on the label could be open to interpretations)

@Diego - agree this is an alternative but again it is abstraction away from the expressed clinical requirements, which needs to be explained to new devs and modellers. The more we can reduce the gaps between requirements and implementation the better.

@Thomas - I'm not sure the SNOMED guys like the pre-coordinated negations much either but like it or not they do exist and will continue to do so. In any case, nothing to stop the binding being made to a post-coordinated expression.

Could this be seen similar to an alternative of DV_ORDINAL with values '0' for false and '1' for true? It would allow to define codes locally or remotely in the symbol part.

Is SNOMED CT now routinely including negations of everything that can possibly said to exist or have occurred? Terrible strategy... but then I would have to agree with your original idea.