I’m using the Procedure archetype and want to record structured details of the procedure under the “procedure details” slot based on what the procedure is. For eg: CPR procedure cluster if the procedure is CPR, Laryngoscopy procedure cluster if the procedure is laryngoscopy etc.
Is there a way to have multiple archetypes under the same slot in a template and choose between them during runtime?
The question is similar to Choice between data element and SLOT? but not quite the same.
In principle is no different of having a choice in any given place, but slot would need to have a maximum occurrences of more than one in the first place. In our implementation, we first clone the slot and give it a new virtual atcode, and then resolve it with the archetype we need
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.
Then I think having a mega template with all possible clusters is the current solution.
How do you do this? Is this done at the time of creation of the template? Or at runtime?
Neither really, it’s on the mapping specification step (but it should be closer to the template creation step, where you should be able to solve a slot twice)
Just-in-time incremental archetype → template generation at runtime, much of which can be precomputed… but nesting of slots/archetypes requires incremental instantiation.