I’m coming back to this on the basis of this topic
which was really raised because of an attempt to do something very similar to the idea of a ‘dynamic template’.
By that we mean that a template can in some way be extended at run-time to allow dynamic validation of a composition.
A classic use-case is the GP consultation where an almost infinite number of Observation archetypes might need to be used to cover all the clinical possibilities.
The normal solution is the ‘mega-template’ but this does become unmanagable at some point.
I wondered about the another possibility, possibly enabled by ADL2, which handle Entry level templates (embedded templates) more elegantly, and the ability to leave slots open and fillable at run-time.
The core of a GP Encounter is a traditional Composition template but it is possible for the app, at run-time to fill any valid open slots with Entry level templated data, as long as these Entry-level templates are registered on the CDR (essentially as .opts).
When the composition is committed, the Entry-level TemplateId is carried in ENTRY.LOCATABLE.archetype_details.
At commit the CDR would assemble a virtual .opt against which to validate the Composition.
Could that work. It might even work for Clusters but ?? issues with nesting (or not)