Sibling RM class that can represent terminology information are indistinguishable

Hm. The usual assumption is that the chosen code (and scheme name) will be used as a key in a query to a terminology service to obtain the full definition. There is no assumption that the code provides all the data required to populate the terminology object at runtime.

If ac1 is bound to say http://snomedct.info/id/9000012345678 (in a 'snomedct' binding group) then this can be an intentional ref set definition, which will contain some expression that allows (or not) specific synonyms. Let's assume that ref set is evaluated against SNOMED CT; the result is some set of concept ids. Now, depending on the API of the service, it should normally be possible to return the set of full terminology entities, as instances of some TerminologyConcept class as defined in CTS2 or another API - i.e. it won't be 'CD' but something similar.

So at runtime in the app, the user can now choose the code, normally done by navigating through the human readable code texts; this will result in instantiating an object of the type prescribed by the archetype at that point in the form (let's assume a screen form). So I would expect some sort of operation like:

CD myCD = new CD.fromTerminologyConcept (aTerminologyConcept)

I don't remember the inheritance relationships between CD, CV etc, but if there are some, then somehow the application has to decide which descendant type it needs to create.

Not sure if I answering the original question, but I'd like to know if we agree on the execution model or not. A a basic point, I would not expect to be able to go from a terminology subset associated with an ac-code and know specifically how to instantiate it in the archetype; normally you would expect to have to look at the archetype structure (and even then, if a supertype was stated, maybe you still don't know).

Or else I may not be understanding the problem correctly!

Probably not "fixed" but one of the valid synonyms for the specified code. Being able to define constraint bindings into classes allows the simplification of archetype constraints, as multiple bindings and rules must be defined if you specify it attribute per attribute.

CD[id12] matches {
codeValue matches {[ac1]} --original subset codes
displayName matches {[ac2]} --same subset, but only the description part, also needs a rule to enforce that the description is one for the code
codingSchemeName matches {"SNOMED-CT"} – if you put the binding into the CD, this comes for free and doesn't need to be specified
}

Normally you would just do this:

ELEMENT[id11] matches {
value matches {
CD[id12] matches {
codeValue matches {[ac1]}
}
CV[id13] matches {
codeValue matches {[ac2]}
}
CE[id14] matches {
codeValue matches {[ac3]}
}
}
}

I don't remember the definition of displayName in 21090 - isn't it fixed once you know the codeValue?

but in the second example if you want to also define the subset of displayName you must repeat the binding, and also put something extra to state that codes and display names correspondences must be correct.

Main problem comes when validating and such, as even if you can create a profile to match CD, CV, etc. to TERMINOLOGY_CODE you cannot validate if the data type is the one you chose in the archetype

I will make the example a little more complicated. Imagine that the archetype provides alternatives to different bindings to different terminologies.
ELEMENT[id11] matches {
value matches {
[ac1] --CD
[ac2] --CV
[ac3] --CE

}
}

When you look at the instance, it won't be possible to validate that ac1 is indeed a CD

I think I half understand this... is it because ISO21090 has CS, CD, CV etc? So does it mean you would want to put something like:

ELEMENT[id11] matches {
value matches {CD[ac1]}
}

This works (without the CD), if you have set something in the AOM profile to match classes like CD with the native TERMINOLOGY_CODEin AOM2. See http://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_aom_profile_configuration

I don't think this is needed, because you can remove that configuration, and put:

ELEMENT[id11] matches {
value matches {
CD[id12] matches {
codeValue matches {[ac1]}
}
}
}