This is a different issue ands one that everyone hits sooner or later i.e the variability of the granular data. I know that various implementers have toyed with some kind of dynamic templating/validation but I have not herard of any real success.
At the end of the day, you do have to validate against a set of constraints, and since that also acts to provide the schema for querying that templated data, you need to persist something that equates to the particular instance of data saved. So you might save on the size of a template that carries every optional ‘procedure’ but then you will then have to create per-instance template, or do something clever like using a lot of references embedded templates. AFAIK none of this is supported by any CDR right now.
So, for good or for bad you are probably stuck with the mega-template for now. That’s certainly our current practice but we would try to break things up a little where possible e.g. you might think of splitting out the Procedure record as a separate template / composition from the rest of the record. We did something like that for a GP system - split out things like meds, allergies, referrals from the main content.
It is frustrating but it is hard to see how it can effectively work differently, at least for now. This is the kind of detailed granularity that makes building any healthcare system in any tech stack, really hard.
The mega template is not in itself a problem - it is just the design-time artefact hat is huge (and I guess must slow validation a bit) but if you are doing things correctly . the composition should not be bloated.