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 > -----Original Message----- > From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- > bounces at 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 > the 'art' of the design of the initial and maximal pap archetype. > > Heather > > >-----Original Message----- > >From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- > >bounces at 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? > > > >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 > > > >> -----Original Message----- > >> From: Erik Sundvall [mailto:erisu at 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). > >> > >> On 10/17/07, Koray Atalag <atalagk at yahoo.com> wrote: > >> >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 at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: > >+46-13-227579 > >> _______________________________________________ > >> openEHR-technical mailing list > >> openEHR-technical at openehr.org > >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > >_______________________________________________ > >openEHR-technical mailing list > >openEHR-technical at openehr.org > >http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > > >__________ NOD32 2599 (20071017) Information __________ > > > >This message was checked by NOD32 antivirus system. > >http://www.eset.com > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
