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 Op 18-okt-2007, om 11:24 heeft Heather Leslie het volgende geschreven: > 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
