Two use case for choice are:
1) Within an archetype it is currently common practice to use a CLUSTER containing two optional elements to simulate the real requirement to indicate that the two elements are alternative choices (e.g. age or data of birth). The cluster is actually a redundant level of data that would not be necessary if a choice mechasim was available.
2) Templates that contain an archetype with a slot that allow multiple archetype fillers (e.g. COMPOSITION.problem_list allows EVALUATION.problem, EVALUATION.problem-diagnosis, EVALUATION.problem-diagnosis-histological, EVALUATION.problem-genetic, EVALUATION.injury) need to allow the slot to be filled with a subset of those allowed (e.g. EVALUATION.problem, EVALUATION.problem-diagnosis and EVALUATION.injury) and apply further constraints on those fillers. The resulting operational template will represent this filled slot as an ordered sequence of these EVALUATIONs forcing all the problems to be grouped together, followed by all the diagnosis and finally all the injuries. However, it should be possible for a user to order their problem list as they wish, allowing problems, diagnosis and injuries to be arranged in any combination. Simply making the container non-ordered is not sufficient as this group of problems may need to followed by addition content such as a EVALUATION.clinical_synopsis etc.