# Embedded archetypes - should there be any tooling constraints? **Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153) **Created:** 2007-09-04 11:28 UTC **Views:** 3 **Replies:** 7 **URL:** https://discourse.openehr.org/t/embedded-archetypes-should-there-be-any-tooling-constraints/14675 --- ## Post #1 by @Sam Dear All A design issue has arisen from the NHS team as there is a bug in the archetype editor when you try and embed an archetype in the data page. You do this by clicking the embed archetype check box before you choose the structure type (list, tree, table...). This has traditionally been used to utilise the same structure for ordering as for recording the action as in medication or procedure. It is possible that archetypes could share the same state information (e.g. pulse and blood pressure) and even protocol - but it seems impossible that different archetypes could share the same data. I believe such a situation should be dealt with by specialisation as the data specification really defines the archetype. I am interested in other people's views. The consequence is that the embedding option will not be available in the editor for the data structure. We could put it forward as a change request for an invariant in the reference model (data is not a slot) if people strongly agree and there is no dissent. Cheers, Sam --- ## Post #2 by @sebastian.garde Sam, I agree that it is most likely bad archetype design if one reuses a structure archetype for various archetypes as 'data'\. The editor shouldn't support this as it is more likely than not leading to an inferior design\. I don't see a structure archetype being reused in two data slots\. Not sure however if we are sure enough about this yet to change the reference model for data not to be a slot\. While you probably never want to reuse an archetype in two data slots, one \(probably remote\) possibility could be that you want to reuse a structure archetype that is used as part of an ACTION and INSTRUCTION archetype also within the \(one\) data slot of an OBSERVATION or EVALUATION archetype? I know the following is not a 100% correct example, but simply for the sake of discussing the possibility of this: A medication description \(which is already used in Action and Instruction archetypes\) is being reused in the data part of an Observation archetype to document the titer/actual amount of medicine found in the patient's blood\. \(It's more likely that \- if at all \- only part of the data would be the same and you would use CLUSTER archetypes rather than structure archetypes to do this, but someone else may come up with a better example\.\) Or consider an instruction for a patient to regularly use a bike with \~60 rotations/min and a maximum pulse rate of 150\. The related Action/ Observation \(what of the two would it be\.\.\.?\) could be documented as various between say 55\-65 rotations/min and a constantly changing pulse rate\. Cheers Sebastian --- ## Post #3 by @Dipak_Kalra Dear Sam, When you say: > but it seems impossible that different archetypes could share the same data am I right in recalling that a generic and re-usable part of a "data" tree has usually been defined as a CLUSTER archetype that is then referenced by several different archetypes? ... and, that an ENRY archetype could in theory contain only one referenced (pre-existing) CLUSTER as its sole data content, ... and, that CLUSTER archetypes can themselves be specialised if needed. Could you (or John) give an example of the additional requirement that is now requested? With best wishes, Dipak --- ## Post #4 by @Sam Yes Dipak This allows for part of the data to be shared by different archetypes... The question here is - is it logical to share the entire data structure between an observation, evaluation or the activity description in an instruction or action. My sense is that this is not logically possible. The embedded structures were introduced in the editor as Instruction descriptions and action descriptions can share data values - are very likely to in very practical sorts of instructions. Cheers, Sam Dipak Kalra wrote: --- ## Post #5 by @system Thanks John We do differentiate from plans in a very general sense - such as a recommendation to commence a drug - from an instruction. We would not anticipate that the recommendation would include the fine grain details - this is better recorded as a planned medication. We understand that this is a grey zone but it is not problematic from a clinical point of view - ie clinicians are happy to make recommendations that are not instructions - and instructions that are not yet activated. I do not believe the approach you are suggesting is required or adds clarity but I understand your literal approach. It will be interesting to see what others feel...Sam [details="(attachments)"] ![OceanC\_small.png|74x72](upload://5I367QG2SMJUp18Pt3jF6yz13Ey.png) [/details] --- ## Post #6 by @system Dear all, I'm trying to understand the problem. Apart from archetype tools problems, etc, there is the general notion of archetypes/templates and how they are used in real life situations. Re-use of archetype fragments, the terminology Boundary problem. Archetypes express maximally what can be recorded about a topic. Templates express what in a specific situation will be considered recordable. Archetypes will consist of parts that will be reused in other archetypes. Several archetypes will have nested components. (reusable sub-archetypes) Am I correct to think that these subarchetypes, that can be re-used in archetypes, are in CEN terms General Purpose Information Components (GPICS)? The same fractal approach holds for Templates as reusable information or presentation fragments/patterns. But there there is no CEN European standard for GPICS. Thinking about it for some time. I think that archetypes can be fractal. There are reusable parts of any archetype that for the sake of consistency needs to be reused. Internal or external codelist must be propagated, etc. In principle I can not think of any level of the Reference Model where this can not happen. So at all levels of the document hierarchy one might find reusable constructs. Perhaps in reality reusability in 'structural' components like Composition and Section is less common or preferable. Folders, Entries, Clusters and Elements will have to be reusable and specialisable. In this vein and triggered by the discussion. As Evaluation Archetype: How is handled that there is an intention to use medication in general as a plan, as opposed to surgical treatment? How is handled an intention to use a specific general type of medication. I.e. treat asthma with steroids? Idem when a specific medicine is used? And the same in an Instruction Archetype. In other words how do we deal with Generals and Particulars in archetypes? DO we have special types of archetypes to make this distinction? Or do we rely on the coding system functionality used in archetypes? Or do we have in each archetype a field indicating what is meant" Particular, a (more) specific instance, or a General? This is our version of the "Terminology Boundary Problem". How is this handled? What are the written guidelines? Gerard -- -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: [gfrer@luna.nl](mailto:gfrer@luna.nl) Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 --- ## Post #7 by @Dipak_Kalra Dear John, My "Immunisation Plan" data set in the one pager from last week was probably not well named - it's more an "Immunity Status" than a plan. It is not the same kind of care planning data structure as an openEHR INSTRUCTION would normally be. (It was only a first cut for us to think about.) With best wishes, Dipak --- ## Post #8 by @system Dipak Is it possible to see any literature from that meeting on the clinical list....I think it would be helpful...not too long! Cheers, Sam Dipak Kalra wrote: [details="(attachments)"] ![OceanC\_small.png|74x72](upload://5I367QG2SMJUp18Pt3jF6yz13Ey.png) [/details] --- **Canonical:** https://discourse.openehr.org/t/embedded-archetypes-should-there-be-any-tooling-constraints/14675 **Original content:** https://discourse.openehr.org/t/embedded-archetypes-should-there-be-any-tooling-constraints/14675