View source for Compositional Expressions in HL7 Value Sets

'''Introduction'''
----

Ed Cheetham gave an excellent presentation at the last HL7 Terminfo meeting on the need to define value sets as compositional expressions.   Value set compositional expressions (VSCR) are, not surprisingly, of a level of complexity similar to their pre-coordinated counterparts in SNOMED-CT or other ontology systems.  This indicates that authoring VSCR\’s will require much the same skill set and tooling needed to edit their parent ontologies.  Furthermore, VSCR need to undergo the same rigorous classification and review as their pre-coordinated couterparts, as they will eventually be interpreted by classification engines in day-to-day operation where errors may go undetected.

Given this, I would propose that the VSCR tooling consist of three components:

== Compositional Expression Definition ==
Expressions should be defined in the same environment and classification system that is used for the underlying ontology.  Multi-ontology expressions will need further research and testing before being put to general use. Expressions should be assigned unique identifiers in much the same fashion that pre-coordinated expressions are today.  These identifiers can be either assigned their own namespace (coding scheme) or be taken from the namespace of the containing coding scheme.  The decision on which will be left to the coding scheme provider(s).
It may be possible that the disjunction (or) operator in the outermost part of the value set definition could be relegated to the value set binding step, as this is the default behavior today when more than one concept code is supplied.

== Value Set Binding ==
Compositional expressions will be referenced using a namespace (coding scheme) and identifier (concept code) just as they are today.  Value sets will have an additional property that, when true, indicates that members of the set are all expressions that are computable subtypes of the referenced expression.  (This property already exists in the latest LexGrid model and may be used in non-compositional situations as well).

== Value set interpretation ==

=== Testing for membership === 
A CTS II query will be designed that takes a vocabulary domain, realm and composite expression (we need to get the correct terms from David Markwell – he has two terms that clearly differentiate pre-coordinated concepts from post-coordinated expressions).  The query will return "yes", or "no".  This implies that the same (or similar?) classification rules need to be avilable in both the authoring and runtime environment.

=== Enumerating Membership === 
This may be an interesting challenge, as the number of possible members of the set may be rather large, or even infinite.  We will need to discuss the ability to enumerate individual "axes" of a compositional expression while holding some or all other components fixed.  Additional work needs to be done here.
## Additional features – ability to state the difference between the value set expression and the "challenge" expression?  Ability to state why a "challenge" expression fails?  Others?

== Maintenance == 
There will need to be tools available that will be able to determine whether code system revisions will (or may) impact the value set definition.  Automated mechanisms need to be put into place that allow maintainers to know when this sort of change is going to occur, and workflow and resources need to be allocated to manage this.