# Multiple parents and max number of nested specialized archetypes? **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2007-10-16 15:34 UTC **Views:** 3 **Replies:** 43 **URL:** https://discourse.openehr.org/t/multiple-parents-and-max-number-of-nested-specialized-archetypes/14678 --- ## Post #1 by @Koray_Atalag Hi, I have a question about the referencing of archetypes in specialization\. And also want to know if there is a limit on the number of specializations of archetypes\. For example: A is top level archetype B is specialization of A C has to further specialize B and there is possibility that D also has to further specialize C and so on\. So in theory all childs have to conform to A\. But the question is in C which archetype will be written in 'specialize' section? A or A & B ? I assume it is currently B\. But in theory, possible one in a million, a particular specialized archetype might conform to multiple parents\.\.\.In my opinion this is perfectly possible\. So what happens? The other question is whether ADL or other limits the number of specializations\. Best regards, Koray Atalag, MD, Ph\.D\. Freelance consultant and developer http://koray.pathos-web.org skype: atalagk --- ## Post #2 by @thomas.beale Hi Koray, At the moment we have not seen any need for multiple inheritance in archetypes\. Do you have a particular use case? Note that C specialising B means that C conforms to B and to A\. Nothing special needed to do that\. \- thomas beale Koray Atalag wrote: --- ## Post #3 by @grahamegrieve > At the moment we have not seen any need for multiple inheritance in > archetypes\. I see this as very similar to multiple inheritance in objects\. There is no \*need\*, but there is useful things that can be done\. The question is whether the price is justified\. The use case is relatively simple in concept \- allowing multiple inheritance would allow me to "cross\-cut" concerns\. I could write an archetype that only dealt a narrow aspect of an information structure, such as data integrity issues, and then use it across multiple archetypes, letting them focus on the big picture, not the minutiae of data integrity, which is mostly overlooked but ubiquitiously present\. This would surely be useful for some things\. The problem is the price\. How do you manage it, how would you use it, what does it mean to allow "multiple inheritance"\. The archetype cannot allow anything not allowed in all it's parents \- so they have to "allow" some fairly generic structures\. To actually use it in an instance, the instance is now making claims that become very much more difficult to evaluate\. HL7 templates are an approach to solving this problem\. HL7 static models allow for multiple inheritance, though this can be discovered \(some controversy where discovery safe though\)\. Actually, given the similarity between static models and AOM, it's possible that the algorithm that HL7 uses would be applicable to AOM too\. Because HL7 models allow multiple inheritance by discovery, it is also necessary to represent the multiple applicable constraint models in the instance, greatly complicating the instance and the processing of the instance\. However there are some interesting design patterns that can arise, and that are arising, in the HL7 space as a consequence of this\. So, resist any thought of multiple inheritance in openEHR \- it will greatly complicate matters\. Let HL7 find out whether templates represent a great big hole to fall into, or whether they will be truly enabling\. \(btw what I have described is not all that templates are in HL7, so the mere fact that templates are successful, particularly in CDA, is not evidence that multiple inheritance can be made to work\) Grahame --- ## Post #4 by @system Dear Graham, Is multiple inheritance in the use case you presented, the only solution? I expect it is not. So why use it. When 'data integrity' is a recurring issue in several archetypes, re-use by inclusion of a 'data integrity' archetype in an other archetypes is a better other solution. I'm not closely following HL7 Templates. Are the HL7 Templates a separate and diverging piece of work when compared to EN13606-2 or harmonising? Do both the HL7 Templates and CEN Archetypes share identical requiremenets? 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 #5 by @grahamegrieve > Is multiple inheritance in the use case you presented, the only solution? > I expect it is not\. > So why use it\. > When 'data integrity' is a recurring issue in several archetypes, re\-use > by inclusion of a 'data integrity' archetype in an other archetypes is > a better other solution\. It would be better if you didn't have to do that \- didn't have to consider \*everything\* in each design\. But on balance, I believe that multiple inheritance raises more problems that it solves\. > I'm not closely following HL7 Templates\. > Are the HL7 Templates a separate and diverging piece of work when > compared to EN13606\-2 or harmonising? There is no simple answer to that\. Really, it's the wrong question\. It's like asking whether the icing on the cake is helping make two totally different cakes the same or not\. > Do both the HL7 Templates and CEN Archetypes share identical requiremenets? again, this is hard to answer\. Archetypes and Static models share very similar requirements \- they are both constraint and ontology binding models\. Templates is a way of re\-using the constraint models in a form that the openEHR/13606 community have not tried to investigate; the design intends to meet those requirements differently\. Only time will tell which is the right approach\. Grahame --- ## Post #6 by @system Dear Graham, Thank you for your frank answers. It is clear. CEN and HL7 are on diverging paths with respect to Templates and Archetypes. 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 @thomas.beale Grahame Grieve wrote: >> At the moment we have not seen any need for multiple inheritance in >> archetypes\. >>     > I see this as very similar to multiple inheritance in objects\. > There is no \*need\*, but there is useful things that can be done\. > The question is whether the price is justified\. > > The use case is relatively simple in concept \- allowing multiple > inheritance would allow me to "cross\-cut" concerns\. I could write > an archetype that only dealt a narrow aspect of an information > structure, such as data integrity issues, and then use it across > multiple archetypes, letting them focus on the big picture, not > the minutiae of data integrity, which is mostly overlooked but > ubiquitiously present\. >   Hi Grahame, in openEHR at least, data integrity is not defined or solved by archetypes \- it is in the reference model\. \- thomas --- ## Post #8 by @heather.leslie Hi Koray, A practical example of 'C' that is currently in the archetype repository is the Histological Diagnosis archetype \- openEHR\-EHR\-EVALUATION\.problem\-diagnosis\-histological\.v1\.ad Problem \-\-> specialised to Diagnosis \-\-> specialised to Histological Diagnosis \- all of which are in the 'Specialisation' field of the Archetype Editor\. There is no technical limit on the number of specialisations \- but from my experience so far, it will be uncommon to have to specialise more than twice\. The modelling required to work out the parent, and then each layer of children becomes increasingly complex and time\-consuming, reconciling back up to the parent once the lowest level of child requirements has been captured \- I have experimented initially with mindmapping for these problems\. To date they have been mainly related to principles of inspection and palpation in cluster archetypes focused on capturing examination for re\-use eg an initial generic inspection cluster, specialised to inspection of skin, to inspection of a wound or inspection of a rash\. Regards Heather --- ## Post #9 by @grahamegrieve hi Tom We are speaking about data integrity issues at different levels\. Of course the reference model assures data integrity at that level; I was speaking of data integrity at the of data aquisition \- calibration, methodology, attribution, these kind of things\. Grahame Thomas Beale wrote: --- ## Post #10 by @thomas.beale Grahame Grieve wrote: > hi Tom > > We are speaking about data integrity issues at different > levels\. Of course the reference model assures data integrity > at that level; I was speaking of data integrity at the of > data aquisition \- calibration, methodology, attribution, these > kind of things\. > > Grahame > ah \- 'data quality' in other words \- i\.e\. markers / meta\-data relating to the data capture from the source, not the integrity of the data as represented on the openEHR system? So far I would see such things as being catered for using compositions of archetypes \- we currently have a lot of Cluster and Structure archetypes for this purpose\. In all Entry archetypes \(Observation etc\), there is a 'protocol' attribute\. It would be easy to create an item under protocol in those Entry archetypes that need it for 'data quality', which is a slot taking a subset of Cluster or Structure archetypes which report on data quality / capture\. We already do a lot of re\-use of this kind with archetypes\. I would be very hesitant to introduce the equivalent of multiple inheritance, because the true nature of inheritance is a notion of substitutability, or IS\-A\-ness\. Using inheritance as a way of doing a mixin as can be done in software can be confusing\. It is interesting that even the Eiffel language, which has the smoothest and cleanest implementation of multiple inheritance \(which Eiffel developrs use ubiquitously in application development\), has evlved its semantics to distinguish 'conforming inheritance' and 'non\-conforming inheritance'\. The latter does not confer substitutability\. In the archetype space, 'substitutability' really translates to: can I use a parent archetype to process the data creating using child archetypes? The answer should \(in my view\) only be yes when the parent is ontologically a precursor of the children, e\.g\. the laboratory archetype is an ontological parent of laboratory\-lipids\. I think it would be hard to push the idea that some archetype containing no constraints apart from some data\_quality items was an ontological parent of laboratory\-lipids or any other archetype\. If we were to go more towards using software constructs in archetypes, I think I would be more interested in genericity \(i\.e\. template types\) rather than multiple inheritance\. \- thomas --- ## Post #11 by @thomas.beale I should note that in the next generation of archetypes and tooling, archetype 'source' files for specialised archetypes will be 'differential' in nature \- i\.e\. valid ADL, but containing only added and changed items from the parent, just as for subclasses in an object\-oriented programming environment\. This will not affect archetypes already created, other than to generate warnings for inconsistencies\. Over time, the tools will migrate to working off the differential source form, not the inheritance\-flattened form we use today \(with the difference only manifesting for specialised archetypes\)\. The current generation of the ADL worbench already shows the inherited items that are changed or added in specialised archetypes\. The next release will enable the source files to be displayed, and will generate the appropriate warnings due to more sophisticated validation up the specialisation lineage\. In practical terms, this translates to more maintainable archetypes and a better ability to see the differences between a given specialised archetype and the parent\. \- thomas beale --- ## Post #12 by @Andrew_Patterson > I should note that in the next generation of archetypes and tooling, > archetype 'source' files for specialised archetypes will be > 'differential' in nature \- i\.e\. valid ADL, but containing only added and > changed items from the parent, just as for subclasses in an > object\-oriented programming environment\. This is excellent news \- I was going to launch into a tirade this afternoon about how archetype specialisation requires repeating the whole parent definition, and how much more robust OO subclassing is because of the differential nature\! Good thing I held off on my venting\.\. :\) A while back there was talk of a confluence wiki being set up for storing of some of these thoughts?? Is anything happening in that area? I can help out if any admin is required \- I just installed Jira and Confluence on my own machines\.\. Andrew --- ## Post #13 by @thomas.beale Andrew Patterson wrote: >> I should note that in the next generation of archetypes and tooling, >> archetype 'source' files for specialised archetypes will be >> 'differential' in nature \- i\.e\. valid ADL, but containing only added and >> changed items from the parent, just as for subclasses in an >> object\-oriented programming environment\. >>     > This is excellent news \- I was going to launch into a tirade this > afternoon about how archetype specialisation requires repeating > the whole parent definition, and how much more robust OO subclassing > is because of the differential nature\! Good thing I held off on my venting\.\. :\) >   we have actually generated differential form archetypes \- we are now adjusting some of the parser semantics, since now it has to check up the specialisation lineage for codes and a few other things, not just in the current archetype\. A few weeks away from being solid I would say\. Also, the ADL workbench now works more like a compiler \- you can see what is compiled, what is not, and quickly reload anything already compiled\. > A while back there was talk of a confluence wiki being set up > for storing of some of these thoughts?? Is anything happening in > that area? I can help out if any admin is required \- I just installed Jira > and Confluence on my own machines\.\. >   they are both going \- as is the new website\. All will be available very soon\. For confluence, we will ust put in some minimal structure to save us from complete disorganisation \- it will be an open wki\. There will be plenty of opportunity for experts here to contribute and help shape these things \- we just want them running in a basic reasonable form so people don't hate us when they see it ;\-\) \- thomas beale --- ## Post #14 by @Koray_Atalag Hi Heather and others, Thanks for the example; I agree that increasing the number of nested specializations will make it difficult to maintain models\. Regarding 'multiple\-inheritance' the probable use case is related with modeling of cervicco\-vaginal smears\. There are now two alternative archetypes, one designed for NHS by Ocean which is already a specialization of general histology archetype and the other archetype I am currently modeling, Bethesda System 2001\. I have not experimented yet if my archetype can be redesigned as a specialization of NHS archetype \(PAP\) or be a an alternative archetype for the same purpose possibly for use at a different setting\. In the case of having two separate alternative archetypes, I thought of having a further specialized archetype which conforms to both parents\. I think this is possible and useful\. In my former message, with the question of writing down B and A for spelicalization section of C, I was proposing to write down the names of all archetypes till the top level in specialization archetype\- like an absolute specialization path\. This I think is not true multiple\-inheritance as in any instance of this specialized archetype, it will conform to only one parent and not inherit non\-conforming stuff from both parents, but the applications working at the level of the parent archetypes shall be able to use this data seamlessly\. Maybe ridiculous but I want to name it as 'multiple\-generalization' :D I do not consider myself a good programmer but I am aware of the shortcomings of multiple\-inheritance in that domain\. However as I explained above I don not feel it really is the same thing\.\.\.And I can perfectly live without this if the price to pay does not worth the benefit ;\) Best regards, \-koray --- ## Post #15 by @erik.sundvall Hi\! Interesting discussion\. I'm hope we can avoid multiple inheritance in archetype specialisation\. It will be interesting to see how far one can get just using single inheritance and inclusion \(clusters etc\)\. > There are now two alternative archetypes, one designed for NHS by Ocean which > is already a specialization of general histology archetype and the other archetype > I am currently modeling, Bethesda System 2001\. I have not experimented yet if > my archetype can be redesigned as a specialization of NHS archetype \(PAP\) > or be a an alternative archetype for the same purpose possibly for use at a different > setting\. In the case of having two separate alternative archetypes, I thought of > having a further specialized archetype which conforms to both parents\. I think > this is possible and useful\. What is different and what is in common in the two 'smear' archetype approaches \(Bethesda v\.s\. NHS\)? Sorry if this is a stupid question coming from a non\-clinician\. Does the reasoning in the paper\.\.\. http://www.openehr.org/publications/archetypes/templates_and_archetypes_heard_et_al.pdf \.\.\.regarding organisational vs ontological models apply to this or are the differences of another nature? Can one share important sub\-parts without sharing view on process and structure\. If so, will the information entered using the two different archetypes be computable in a similar way for e\.g\. decision support systems\. Perhaps the best will be to agree on one archetype in this case if possible, but I assume similar cases will surface again\. From a technical perspective it is interesting to discuss how far one can get in reaching clinical consensus in 'ontological' sub parts\. Splitting things up in too many small 'consensus pieces' without sharing encompassing structure is also likely to have negative impact on semantic interoperability\. Best regards, Erik Sundvall erisu@imt\.liu\.se http://www.imt.liu.se/~erisu/ Tel: \+46\-13\-227579 --- ## Post #16 by @system Koray Lets get the requirements on the Clinical list and have a discussion. I did not see large inconsistencies in the content in the two - rather differences in modelling approaches. Cheers, Sma Koray Atalag wrote: [details="(attachments)"] ![OceanC\_small.png|74x72](upload://5I367QG2SMJUp18Pt3jF6yz13Ey.png) [/details] --- ## Post #17 by @sebastian.garde Hi, I also think we should avoid multiple inheritance \- it is complex enough the way it is \- from a tooling as well as from an archetype design point of view\. We don't need to make it complicated in addition to complex\. Like Erik, I don't know the details of these two archetypes, but I think a better design than using multiple inheritance would be to \- use a common base archetype for both\. Here everything that the two archetypes have in common \(even if it is a little bit more generic than it would be when only considering one of them\) can be located\. And also everything that doesn't largely overlap can be located as optional items \- even if it doesn't have any relevance to the NHS and or Bethesda\. \- If really necessary specialise this base archetype for the environment, but preferably use templates to achieve this \(strip out unnecessary items in your environment, further constrain the archetype etc\.\) Cheers Sebastian > From: Erik Sundvall \[mailto:erisu@imt.liu.se] > Sent: Thursday, 18 October 2007 5:04 PM > To: For openEHR technical discussions > Subject: Re: Multiple parents and max number of nested specialized > archetypes? > > Hi\! > > Interesting discussion\. I'm hope we can avoid multiple inheritance in > archetype specialisation\. It will be interesting to see how far one > can get just using single inheritance and inclusion \(clusters etc\)\. > > >There are now two alternative archetypes, one designed for NHS by Ocean > which > > is already a specialization of general histology archetype and the other > archetype > > I am currently modeling, Bethesda System 2001\. I have not experimented > yet if > > my archetype can be redesigned as a specialization of NHS archetype > \(PAP\) > > or be a an alternative archetype for the same purpose possibly for use > at a different > > setting\. In the case of having two separate alternative archetypes, I > thought of > > having a further specialized archetype which conforms to both parents\. I > think > > this is possible and useful\. > > What is different and what is in common in the two 'smear' archetype > approaches \(Bethesda v\.s\. NHS\)? Sorry if this is a stupid question > coming from a non\-clinician\. > > Does the reasoning in the paper\.\.\. > http://www.openehr.org/publications/archetypes/templates_and_archetypes_ he > ard\_et\_al\.pdf > \.\.\.regarding organisational vs ontological models apply to this or are > the differences of another nature? > > Can one share important sub\-parts without sharing view on process and > structure\. If so, will the information entered using the two different > archetypes be computable in a similar way for e\.g\. decision support > systems\. > > Perhaps the best will be to agree on one archetype in this case if > possible, but I assume similar cases will surface again\. From a > technical perspective it is interesting to discuss how far one can get > in reaching clinical consensus in 'ontological' sub parts\. Splitting > things up in too many small 'consensus pieces' without sharing > encompassing structure is also likely to have negative impact on > semantic interoperability\. > > Best regards, > Erik Sundvall > erisu@imt\.liu\.se http://www.imt.liu.se/~erisu/ Tel: \+46\-13\-227579 --- ## Post #18 by @thomas.beale Koray Atalag wrote: > > In my former message, with the question of writing down B and A for spelicalization section of C, I was proposing to write down the names of all archetypes till the top level in specialization archetype\- like an absolute specialization path\. This I think is not true multiple\-inheritance as in any instance of this specialized archetype, it will conform to only one parent and not inherit non\-conforming stuff from both parents, but the applications working at the level of the parent archetypes shall be able to use this data seamlessly\. Maybe ridiculous but I want to name it as 'multiple\-generalization' :D > Hi Koray, now I understand what you want\. You want the 'inheritance\-flattened' form of a specialisation archetype \- i\.e with everything in it due to all parents\. This happens to be the current form of archeypes anyway\. We are converting over to the differential form used in object\-oriented programming very soon \(in \.adls files\), but the flat form will still be avalable \(\.adl files\), generated and validated rather than directly created as they are today\. In the current form of the \.adl file we don't mention the lineage of parents all the way to the top\. It would be easy enough to do, although I don't quite see what use it would be\. \- thomas --- ## Post #19 by @thomas.beale Erik Sundvall wrote: > Hi\! > > Can one share important sub\-parts without sharing view on process and > structure\. If so, will the information entered using the two different > archetypes be computable in a similar way for e\.g\. decision support > systems\. >   this is why we have Cluster & Structure archetypes that are routinely shared via slots in various other archetypes \- it provides a high degree of re\-use, just as for classes referencing other classes \(assocation, aggregation\) in the object paradigm \. \- thomas --- ## Post #20 by @heather.leslie My approach would is in synch with Sebastian \- ideally one maximum data set of all content for one pap archetype, from any source or standard, then constrained in a template for Bethesda's purposes, NHS' needs etc\. Then the data has maximal interoperability and queryability\. In this case you wouldn't need multiple inheritance \- I think the key is in the 'art' of the design of the initial and maximal pap archetype\. Heather > From: openehr\-technical\-bounces@openehr\.org \[mailto:openehr-technical- > bounces@openehr\.org\] On Behalf Of Sebastian Garde > Sent: Thursday, 18 October 2007 8:46 AM > To: For openEHR technical discussions > Subject: RE: Multiple parents and max number of nested specialized archetypes? --- ## Post #21 by @erik.sundvall Hi\! I know that it is technically possible\. ;\-\) I was trying to ask if it was clinically possible to identify clusters etc in this specific case\. Sorry for not being specific enough in the question\. After I asked some good suggestions regarding template use have been posted as a good reminder that there is usually more than one solution\. Thanks\! // Erik --- ## Post #22 by @Stef_Verlinden1 I agree with Heather, this is the way to go if one wants to accomplish maximal interoperability and queryability\. We should as much as possible try to avoid multiple archetypes for the same knowledge domain because it will restrict exchangeability of data Cheers, Stef --- ## Post #23 by @Stef_Verlinden1 >> > > ah \- 'data quality' in other words \- i\.e\. markers / meta\-data relating > to the data capture from the source, not the integrity of the data as > represented on the openEHR system? I would like to expand that to data quality assurance\. How can one objectively and according to locally accepted standards establish that data is of good quality, i\.e\. \(re\)usable, or should be rejected/ ignored\. IMHO this is one of the crucial points for a functional EHR\. What's the use of a centralized system to store and retrieve semantically interoperable data if the data is of poor/unknown quality\. It also has a legal aspect\. When one uses data provided by a third party one also takes over/ shares responsibility from/with that third party if one willingly accept data of poor quality\. My guess is that not many people want to do that\. Cheers, Stef --- ## Post #24 by @heather.leslie Hi Erik, Yes, clusters used in the way you describe can be queried upon just like any other class of archetype\. It is one way to handle these issues, but still the 'purer' methodology for a Pap smear report, in this case, would be to aim for a maximal Pap report archetype and use the template to constrain it for specific purpose\. Clusters are in use all through the NHS archetypes/templates\. I have found them especially useful in examination\-related archetypes for very simple and universal concepts eg dimension, inspection, etc\. These clusters will pop up amongst a large range of archetypes\. So you will be able to query for a width or length in whatever part of the EHR a dimension cluster is used\. I guess that it could follow that it is possible to consider using the cluster as the common 'child' archetype within 2 distinct 'parent' entry archetypes to mimic multiple inheritance\. But it is not recommended\. The cluster class has limited functionality compared to entry classes \- eg it is limited without event model etc \- a cluster has just data and no state, events, protocol associated with it\. These data elements would be necessary in a Pap report \- I don't think you could get away with these being in each parent\. After all you are already losing some of the commonality \- the very thing that you are trying to use the cluster for \- if you have to put the same event or state data back up into each 'parent' entry archetype\. Hope this helps clarify rather than confuse\. Heather > From: openehr\-technical\-bounces@openehr\.org \[mailto:openehr-technical- > bounces@openehr\.org\] On Behalf Of Erik Sundvall > Sent: Thursday, 18 October 2007 1:00 PM > To: For openEHR technical discussions > Subject: Re: Multiple parents and max number of nested specialized archetypes? --- ## Post #25 by @system > Hi Erik, > > Yes, clusters used in the way you describe can be queried upon just like any > other class of archetype. It is one way to handle these issues, but still > the 'purer' methodology for a Pap smear report, in this case, would be to > aim for a maximal Pap report archetype and use the template to constrain it > for specific purpose. I agree. > Clusters are in use all through the NHS archetypes/templates. I have found > them especially useful in examination-related archetypes for very simple and > universal concepts eg dimension, inspection, etc. These clusters will pop > up amongst a large range of archetypes. So you will be able to query for a > width or length in whatever part of the EHR a dimension cluster is used. In other words there are 'atomic archetypes'. These 'atomic archetype's re-appear in normal archetypes to be finally constrained in Templates. The Template is the profiling tool to make things explicit in a defined healthcare context. > I guess that it could follow that it is possible to consider using the > cluster as the common 'child' archetype within 2 distinct 'parent' entry > archetypes to mimic multiple inheritance. But it is not recommended. The > cluster class has limited functionality compared to entry classes - eg it is > limited without event model etc - a cluster has just data and no state, > events, protocol associated with it. These data elements would be necessary > in a Pap report - I don't think you could get away with these being in each > parent. After all you are already losing some of the commonality - the very > thing that you are trying to use the cluster for - if you have to put the > same event or state data back up into each 'parent' entry archetype. Here I need some explanatory elaborations to make things very explicit. --- ## Post #26 by @Koray_Atalag Hi, I am still working on a concrete use\-case but now I understand and agree with Heather's recommendation about having a top level parent encompassing all of items for both PAP archetypes\. I just did not know enough about templates to see how it goes\. I guess I need to participate to some openEHR events to have hands on experience with them ;\) For the requirements part I will shortly express them for Bethesda report in the clinical list\. Thanks for all your input\. Cheers, \-koray --- ## Post #27 by @Heath_Frankel3 I have been watching this thread curiously\. We need to remember that Archetype Specialisation is actually a constraining process NOT extension as in OO inheritance\. You can\-not add things that didn't exist in the parent, only provide more specific semantics\. Using laboratory observation archetype as an example, the Any Result element can be used to record anything of any type, but in the laboratory\-lipids this Any Result has added additional semantics to Any Result to give mean to data elements such as Total Cholesterol as a quantity type, LDL as a quantity, HDL as a quantity, etc\. These are not new data elements but constraints on the existing Any Result element\. Therefore, there must be generic concepts in the base archetype that can be used in specialised archetypes that can be further constrained\. I think this is in\-line with what Sebastian and Heather are suggesting\. Heath > From: openehr\-technical\-bounces@openehr\.org \[mailto:openehr-technical- > bounces@openehr\.org\] On Behalf Of Heather Leslie > Sent: Thursday, 18 October 2007 6:55 PM > To: 'For openEHR technical discussions' > Subject: RE: Multiple parents and max number of nested specialized archetypes? > > My approach would is in synch with Sebastian \- ideally one maximum data set > of all content for one pap archetype, from any source or standard, then > constrained in a template for Bethesda's purposes, NHS' needs etc\. Then the > data has maximal interoperability and queryability\. > > In this case you wouldn't need multiple inheritance \- I think the key is in --- ## Post #28 by @system Heath Templates are the main means of constraint on archetypes - Specialisations are mainly about adding attributes. Consider the scenario where an organisation requires attributes on an archetype that are not available. They will have two choices - to push for a revision of the source archetype with the addition of their attribute as an optional element OR creating a specialisation of the archetype for local use. Both enable them to proceed, for their data to be queried by all etc. Hope this is helpful. Cheers, Sam Heath Frankel wrote: [details="(attachments)"] ![OceanC\_small.png|74x72](upload://5I367QG2SMJUp18Pt3jF6yz13Ey.png) [/details] --- ## Post #29 by @Andrew_Patterson > Templates are the main means of constraint on archetypes \- Specialisations are mainly > about adding attributes\. Sam, surely those attributes are available by virtue of the fact that the parent archetype says nothing about them\. Something in an archetype can never 'add' an attribute\. All archetypes can do is constrain\. And the specialised archetype can never remove a constraint of the parent surely? For example, an observation archetype that says nothing about the 'State' attribute imposes no constraints on that attribute\. A specialisation of the archetype could impose extra constraints on 'State', but can't add the attribute in\. I mean, there is either a 'state' attribute there in the RM or not \- the archetype can't add attributes\. Of course this all leads to a much more interesting theoretical question \- aside from the immediate syntactic differences, what exactly is the difference between a template and a specialisation? Andrew --- ## Post #30 by @system > > Templates are the main means of constraint on archetypes - Specialisations are mainly > > about adding attributes. > > Sam, surely those attributes are available by virtue of the fact that the parent > archetype says nothing about them. Something in an archetype can never 'add' > an attribute. All archetypes can do is constrain. And the specialised archetype > can never remove a constraint of the parent surely? > > For example, an observation archetype that says nothing about the > 'State' attribute > imposes no constraints on that attribute. A specialisation of the > archetype could > impose extra constraints on 'State', but can't add the attribute in. I > mean, there is > either a 'state' attribute there in the RM or not - the archetype > can't add attributes. > > Of course this all leads to a much more interesting theoretical question - aside > from the immediate syntactic differences, what exactly is the difference between > a template and a specialisation? Andrew, this is indeed a very interesting question. It seems to me that all the constraints done in templates can be done with archetypes. The 'artificial' divide between templates and archetypes are probably to do with their different intended uses. Archetypes are semantically coherent and are supposed to be shared between systems. Templates are, on the other hand, created to meet local specific requirements, therefore not supposed to be shared across sites. But the line of distinct seems to be blurred. How local is a local requirement and thus justify the use of a template? Can one start with a template for local use, and later convert the template into an archetype for shared use? Also if all constraints can be expressed using the AOM semantics (which is already very generic and powerful), we perhaps could re-use the same object model to represent template constraints, which would facilitate the conversion between archetypes and templates. Cheers, Rong --- ## Post #31 by @heather.leslie The demarcation between templates and a specialisation are very clear to me – very different entities. Let me start at the beginning, although it may be so obvious to most that you have overlooked it to focus on the constraint issues, but I thought I’d state it for completeness. At the simplest and most obvious level, an archetype is a data specification for a single clinical concept. A specialisation is a type of archetype. A template is an aggregation of archetypes, some of which may be specialised, that are combined to carry out a particular clinical purpose eg a discharge summary. In the following discussion, I will assume that our goal is to design internationally interoperable archetypes, and excludes the specific archetype that is used only for a niche purpose and has no intention of being shared at design time... An archetype, whether specialised or not, in the purest methodological sense, is a MAXIMAL data set for that given single clinical concept – something that seems to often get overlooked when trying to model clinical concepts. It is also a data set that should have the MINIMAL constraints on it, in order to MAXIMISE interoperability. Any constraints that are included in an archetype should be only added when it applies UNIVERSALLY. For example the current Blood Pressure archetype contains constraints for both the Systolic and Diastolic readings, but they are obviously not in keeping with accepted clinical practice - in the realm of 0-1000mmHg or so. Why? – to exclude the real extremes that are clearly and absolute errors, but at the same time giving the freedom for later constraint to practical and usable levels in, preferably and most likely, a template, but also possibly in a specialisation. It is universally acceptable that a systolic blood pressure will not exceed 1000mmHg but there is debate at what is the most reasonable figure, so at design we went for a number that was easy and unlikely to be exceeded – 10 too low, 100 too low, 1000 will work! Could have picked 500 – very unlikely to get a BP over 500, but could never say it was impossible to record – this is a grey zone, so to be universally acceptable, and interoperable, we avoided it. An archetype should be designed for stability and longevity – so it is able to withstand all uses that can be imagined. It will never be possible to imagine all, and so there is the potential to revise archetypes, but it is desirable to keep the revision process to a minimum. Hence the need to consult widely at the time of designing an archetype – across specialties, organisations etc etc to try to gauge all needs. This is a critical component of good archetype design when interoperability is the goal. STABLE archetypes should be the result and that stability is needed to support implementation. Good initial design will minimise impact downstream from having to revise archetypes in systems. The constraints have to be considered as part of this process. Specialisations are used to resolve issues related to the archetyping of overlapping concepts with slightly different information requirements. The reference model allows for new data points to be added in a specialisation (the most common use), and to a lesser degree, permits further constraint on existing data points and for optional data points to be dropped. An example is inspection cluster, specialised to inspection-skin, and further specialised to inspection-skin-rash or inspection-skin-wound – where additional data points have been added to capture the depth and breadth of the more specific aspects of inspection. Note that all still have the original (most unconstrained and generic) inspection archetype in common – and this is important to facilitate effective archetype-enabled querying. Specialisation of an archetype should still hold true to the rule of keeping the archetype as unconstrained as is possible so as to ensure interoperability. Templates are use-case, region-, provider- or enterprise-specific. They comprise multiple archetypes. The beauty of templates is that they are FLEXIBLE – it is a key feature. Combine the stable archetypes in ways that achieve various purposes. Constrain the stable archetypes down to make them more practical and useable for the local clinicians, including making optional data points mandatory and binding data points to terminology subsets appropriate for that given clinical setting. My 20c (more words than a 2c commentJ) Heather --- ## Post #32 by @system We are hitting the philosophical - no one is saying anything contradictory - but we have two levels so lets just consider how to get a clear message: 1. We have a reference model - Compositions, Observations, Clusters, Elements etc. This defines what is possible. 2. We have an archetype definition language - this constrains those possibilities in order to represent sensible things to say consistently in an EHR - so we have an archetype for Apgar or Bartel or Diagnosis. These are, as Andrew says, pure constraints on the reference model. These are the standard reuseable specifications for clinical information that we want to share. 3. We have templates - these say how to put archetypes together to say something more complex - and also how to use an archetype in a particular setting - they only make computational statements about archetypes and constraint statements that are wholely within the constraint statements made by the archetypes they use. 4. We have specialised archetypes which take all the constraint statements made by a parent archetype and add more - importantly they can make further constraint statements about the reference model - this is what I mean when I say that a specialised archetype might add an element. Importantly it will have a larger ontology than the parent - it may make a statement that is not in the parent. Yes - these are still constraint statements on the reference model but they are additional to the parent. They do not have to be wholely within the parent archetype - only whole consistent with it but have additional statements that are unknown to the parent. An example is the Diagnostic Criteria cluster in Diagnosis (openEHR-EHR-EVALUATION-problem-diagnosis) that is not in the parent archetype Problem (openEHR-EHR-EVALUATION-problem). Is this clearer? Cheers, Sam Rong Chen wrote: [details="(attachments)"] ![OceanC\_small.png|74x72](upload://5I367QG2SMJUp18Pt3jF6yz13Ey.png) [/details] --- ## Post #33 by @Alain_Maskens Great explanation, clear and useful. Thank you. Alain Maskens HEALTH One Global --- ## Post #34 by @Peter_Gummer1 Sam Heard wrote: > We have specialised archetypes which take all the constraint > statements made by a parent archetype and add more - > importantly they can make further constraint statements > about the reference model - this is what I mean when I say > that a specialised archetype might add an element. > Importantly it will have a larger ontology than the parent - > it may make a statement that is not in the parent. > Yes - these are still constraint statements on the reference > model but they are additional to the parent. They do not > have to be wholely within the parent archetype - only > whole consistent with it but have additional statements > that are unknown to the parent. That sounds very much the same to me as the "extension-specialization paradox", as described by Meyer, "Object-Oriented Software Construction", 2nd edition, page 499: > Inheritance is sometimes viewed as extension and sometimes as specialization. Although these two interpretations appear contradictory, there is truth in both — but not from the same perspective. > > It all depends, again, on whether you look at a class as a type or a module. In the first case, inheritance, or *is*, is clearly specialization; “dog” is a more specialized notion than “animal”, and “rectangle” than “polygon”. This corresponds, as noted, to subset inclusion: if *B* is heir to *A*, the set of run-time objects represented by *B* is a subset of the corresponding set for *A*. > > But from the module perspective, where a class is viewed as a provider of services, *B* implements the services (features) of *A* plus its own. *Fewer* objects often allows *more* features, since it implies a higher information value; going from arbitrary animals to dogs we can add the specific property of barking, and from arbitrary polygons to rectangles we can add the feature *diagonal*. So with respect to features implemented the subsetting goes the other way: the features applicable to instances of *A* are a subset of those for instances of *B*. ... > > Inheritance, then, is specialization from the type viewpoint and extension from the module viewpoint. This is the extension-specialization paradox: more features to apply, hence fewer objects to apply them to. - Peter Gummer --- ## Post #35 by @Dipak_Kalra Dear Heather, Your 50c worth is really an excellent explanation. Well done, and I hope many readers on the list will find it helpful. With best wishes, Dipak --- ## Post #36 by @Greg_Caulton A couple more questions \(by the way Leslies description was awesome and makes total sense\)\. Interfaces a\) When creating a generic outbound or inbound interface with an extrernal system \- do you build based upon the archetypes only \- i\.e\. provide as many values possible? or your specializations? or is this all mute and we stick with HL7? Templates, as a collection for a use case\. I looked out in Subversion but only see one out there: http://svn.openehr.org/knowledge/templates/dev/html/ b\) Do templates or specializations or archetypes define workflow e\.g\. record results, based upon results collect additional information or not?' In the case were a doc just wants to replicate a paper form but not improve it would I build a template or stick with Archetypes? So implementing a form like this: http://home.cogeco.ca/~epiphany/FPDoctor-Perfect-Progress-Note-2.0.pdf thanks\! Greg Caulton Boston, MA http://www.patientos.org --- ## Post #37 by @Hugh_Leslie1 Hi All I think that there is a clear need for a distinction between archetypes (specialized or not) and templates and this relates mainly as Rong has said as to their intended use. Archetypes are for interoperability and so they need to be designed to be able to handle any usage of the particular concept that they are modelling. This means that valid ranges in archetypes should be set so that valid values will never fall outside the range. ie the bp archetype sets the max systolic value to 1000. Archetypes should be kept as generic as possible for the particular concept and are maximal data sets and so should contain every concept that is required for any use of that concept. Templates are specific use cases of a particular archetype or groups of archetypes and can be constrained down for a particular usage ie for the bp archetype, you may constrain it to just contain the systolic and diastolic in an 'any event' and remove any other non mandatory elements. Templates are useful for turning a generic archetype into something more specific i.e. the laboratory archetype can be constrained in a template (or at runtime) to be a specific type of laboratory result. This means that instead of 5000 specific laboratory archetypes, we only need one generic and probably 20 or 30 agreed specializations. Templates can also be used for creating very complex documents such as an antenatal visit which is made up of many different archetypes. Templates can be made up of nested archetypes as well as nested templates all of which can be further constrained within the limits of the archetypes used - this allows for the development of concepts and documents with any arbitrary level of complexity that still conform to archetypes. The question has been raised as to the difference between a specialization of an archetype and a template and when to use each. There is no absolute answer to this, but there is a need to examine the need for specializations of archetypes to see whether the archetype is general enough to be used **everywhere**. If it meets this test, then it is reasonable to create it and submit it as an archetype, otherwise a template should be used constraining some more general archetype. I think that over time it will become clear that there are some templates that should become archetypes. regards Hugh Rong Chen wrote: --- ## Post #38 by @sebastian.garde Hi Could we put the comments of the two H. Leslies on the openEHR.org FAQs somewhere? I think together they are the best explanation of archetypes, templates, and their distinction that I have read so far. Sebastian --- ## Post #39 by @Lisa_Thurston1 Hi all I think that in the absence of a template specification it is indeed difficult to see, from a technical viewpoint, the difference between templates and "aggregation archetypes" (which is what I think Rong means by "all the constraints done in templates can be done with archetypes"). Heather and Hugh point out that such archetypes would not be universal in their applicability and therefore less shareable. This still leaves a blurry line between where the archetype ends and the template begins. There are some features of templates that do make this line clear, however. The best example I can think of is default values (not to be confused with assumed values). At some point you'll want to be able to say things like "the default temperature scale is Centigrade" or "the default number of foeti is 1". If the default value is free text or even a coded term, this implies that the template is targeted to a specific language/culture, thus NOT universal. Therefore the template specification, when it arrives, is likely to include ways to define default values and the target language/culture of the template. A template is language/culture-specific. There is provision made for default values in the AOM's archetype constraint model but the TYPE of a default is left open. Since the TYPE of these values cannot be constrained by the AOM, default values can never be meaningfully applied in ADL. Rather they can only be applied in the template (which knows about the reference model and target language/culture of the data). This connects to Rong's point about expressing template constraints in AOM semantics. I fully agree the template specification should make use all useful parts of the archetype constraint model or "build on top of" the AOM. If a template was ever suddenly considered to encapsulate a structure which was universally (or near-universally) applicable, as Hugh suggests, the default values would have to be discarded (as well as other culture-specific structures or assumptions). And for the archetype to be practical in a more universal sense, any items added to the ontology in the template (in the template's target language) would probably need to be translated into the other languages. Therein lies the distinction. Regards Lisa Hugh Leslie wrote: --- ## Post #40 by @Heath_Frankel3 I haven’t followed this whole thread, in particular I haven’t seen Rong’s emails about templates and aggregation archetypes but I thought I would provide a little input about the future of the template specifications. If you have a look at the Template Object Model as published as a draft in R1.0.1 you will find two packages. The first is the TEMPLATE_SPEC package. This provides a mechanism to specify a template using references to archetypes and aggregating them together. In addition it provides a series of constraint rules of various kinds to do things like constrain cardinalities or specify default values. We have been recently comparing this with the current proprietary template definition used within the Ocean Template Designer and have found that there are very few required template semantics that cannot be expressed using the R1.0.1 TEMPLATE_SPEC draft. The second model is the operational template model. We have actually implemented this and have needed to augment and change this model slightly, but the principles expressed in the R1.0.1 draft (a Template object with definition specified by a C_COMPLEX_OBJECT and list of path and default value pairs) has work fine. This implementation experience will be feed back into the openEHR community for the next release. So in summary, Rong’s premise that we can express templates using the AOM is true, but what he calls an “aggregation archetype” is an operational template. The TEMPLATE_SPEC is just another representation of the same template where it references the existing archetype artefacts and constrains them using rules. The TEMPLATE_SPEC is used to store and maintain the template definition within an authoring environment while the operational template is derived from the TEMPLATE_SPEC and is used within software at run-time. We are just completing the testing of a new export function in the Ocean Template Designer that generates an operational template from its proprietary template definition. This operational template will be used for all sort of purposes including the generation and validation of RM objects that conform to the template. Hope this helps keep you up to date with progress in this area. If you have interest in this area from the technical perspective I suggest that we progress this further in a collaborative manner. Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph: +61 (0)8 8223 3075 mb: +61 (0)412 030 741 email: [heath.frankel@oceaninformatics.com](mailto:heath.frankel@oceaninformatics.biz) --- ## Post #41 by @system Thanks all for the excellent explanations on the differences between archetypes and templates both from functional and technical point of view. I agree with Sebastian, these rather educational comments should be included in our FAQ page. On the technical side, I will be glad to review the early draft of TEMPLATE_SPEC specification. It can even be implemented by the Java community to provide feedbacks for further refinement. Cheers, Rong --- ## Post #42 by @system Hi Greg > ``` > Interfaces > > a) When creating a generic outbound or inbound interface with an > extrernal system - do you build based upon the archetypes only - i.e. > provide as many values possible? or your specializations? or is this > all mute and we stick with HL7? > > ``` HL7 will be around forever - openEHR merely starts from the coherent and extensible EHR and aims to keep as much information as possible in a form that can be queried (and processed). If you want to ask a question in the openEHR environment then you do so in terms of the reference model and archetypes (which are always composed of reference model types). So if we have an archetype for blood pressure then we can recall all blood pressures - and then any part of that information group. So when you say interfaces - the raw interface itself knows only the reference model - but the query engine understands that archetypes exist and how they are 'stamped' in the data. At a coarse grain level, the EHR consists of compositions - which remain the coherent view of the health information - as a document like CDA does. > ``` > Templates, as a collection for a use case. I looked out in Subversion > but only see one out there: > [http://svn.openehr.org/knowledge/templates/dev/html/](http://svn.openehr.org/knowledge/templates/dev/html/) > > ``` You need to look at the UK site: ..templates\dev-uk-nhs\xml\openehr\ehr > ``` > b) Do templates or specializations or archetypes define workflow > e.g. > record results, based upon results collect additional information or not?' > > ``` All health record entries record workflow to some extent. Observations record measurements and findings, Evaluations record assessments and summaries, Instructions record orders and Actions record interventions or things done (or not done if required). It might take a while to think of an order for a lab (instruction) resulting in blood being taken (can be recorded as an action), being sent to the lab, being processed, being sent back to the sender, being checked by the ordering clinician, being completed - all actions. The actual result will be an observation - which is linked to the order but is not an action arising from the order. > ``` > In the case were a doc just wants to replicate a paper form but not > improve it would I build a template or stick with Archetypes? So > implementing a form like this: > > [http://home.cogeco.ca/~epiphany/FPDoctor-Perfect-Progress-Note-2.0.pdf](http://home.cogeco.ca/~epiphany/FPDoctor-Perfect-Progress-Note-2.0.pdf) > > ``` The link didn't work - but one design issue for those building archetypes is to consider the fact that some data will be entered in a narrative form - perhaps a great deal in some settings. This means we might only get minimal structure in 3 or 4 archetypes in some situations. Hope that is helpful, Sam [details="(attachments)"] ![OceanC\_small.png|74x72](upload://5I367QG2SMJUp18Pt3jF6yz13Ey.png) [/details] --- ## Post #43 by @thomas.beale Dipak Kalra wrote: > Dear Heather, > > Your 50c worth is really an excellent explanation\. Well done, and I > hope many readers on the list will find it helpful\. > You should see what Heather can do for $1\.\.\.\. \- thomas --- ## Post #44 by @Koray_Atalag Dear All, I have an important modeling problem in ADL for defining whether single or multiple selection is allowed for values of an ELEMENT\. In \(very informal\) other words checkbox or option box\. During a recent discussion with Thomas, I learned that this has previously been discussed and that current trend is to move this into templates together with the constraint about default values\. I can perfectly understand and appreciate to define default values in templates as they can be dependent on regional, cultural or even religious matters\. But considering the principles expressed \(wonderfully\) in a previous thread about archetypes and templates, one can simply come to a conclusion that \(almost\) universal and non\-volatile domain knowledge go into former while local/volatile knowledge go into latter\. In any concept such constraints are an integral part of that domain knowledge; i\.e\. an ELEMENT defining presence of bleeding can not have both present and absent\. Of course then there might be other cases where this can not be determined in advance\- so you simply do not constrain them in archetypes and handle with local templates\. The rationale behind my similar requests/suggestions is very simple: I prefer to be able to model concepts and implement them without depending on templates; just archetypes and that's all\. I know that this is not the mainstream approach/business model but it can improve stability of archetypes and add flexibility in openEHR/CEN implementations\. Best regards, Koray Atalag, MD, Ph\.D\. --- **Canonical:** https://discourse.openehr.org/t/multiple-parents-and-max-number-of-nested-specialized-archetypes/14678 **Original content:** https://discourse.openehr.org/t/multiple-parents-and-max-number-of-nested-specialized-archetypes/14678