Hi Gerard, I do not appear to have all of the original inputs to this thread, so I am not sure who made some of the original comments.
*Specialisation* > Since archetypes express what can be maximally documented about a topic, > and because in the Template the archetype can be constrained maximally to > fit the local context at that point in time, > I think there is almost no need for specialization. > I almost agree - we should, I think make sparing use of specialisation but some good use cases are emerging -see below. > > *In the example given below. It is clear that both BW and BWB example at > the same time Body weight and Body weight at the time of birth can be > generically handled and do not need specialization.* > *Body weight change is always relative to an other measurement. I see no > reason why these aspects of what can be documented around the topic Body > weight can not be in the same archetype. At Template design time > the appropriate attributes will be selected or deselected.* > > *A possible example* > *There is the generic Weight archetype as an Observation. Expressing all > that can be documented about any weight observation.* > *And then we define a specific specialized one for Body weight or Organ > weight or thumb weight or compound weight, etc, etc, etc* > *I do not think this is the way to go. The world is large and to > many specialization's will be produced.* > I disagree, Birth weight is a good example of an appropriate specialisation. It is a clearly understood and accepted specialisation of body weight which has quite specific and universally agreed constraints across all possible uses of the concept. ** > *I think it is wrong to have an archetype called Body weight. We only need > ONE about all aspects of WEIGHT of anything.* > * > * > *My line of thinking is:* > *When all that can be documented about a concept is defined in an > Archetype and the concept is weight than the topic is about weight > measurement of anything.* > *Within the archetype there must be an attribute what the focus of the > concept is. So we must be able to indicate in an archetype attribute whether > this a person or a thing.* > *It must be possible to indicate what is observed.* > ** > Again I must disagree. The value of the archetype philosophy as that it allows clinicians to agree the content and contraints upon clinical recording topics which are both manageable but have universality. If we attempt to over abstract the archetype to simply 'weight' and leave all the constraining to the template layer, we will simply end up with the same problems 'downstream'. I can understand from an enginerring perspective the attraction of more pure abstract archetypes but from a clinical recording perspective the Is-a relationship should reach no further back than 'Body weight'. This is the base class. Any other type of weight recording in clinical settings e.g weight of ingredients in a drug is quite a different concetp,although of course, in pure ontological terms it is_a weight. * > * > *At the Template level I see specialized Sections be constructed > containing generic archetypes. Archetypes that define precisely in the > context of measurements in newborns and grownups what will be documented > about weights.* > > I'm curious to learn what are the real use cases for > Archetype specialization. > I see the need for specialization in the Template phase under control of > the knowledge domain. > In the meantime the tools must be able to support specialization. > Several use cases that I can identify: 1. 'True specialisation' The case of Body weight/Birth weight above. I think this is a very good example of appropriate 'true' specialisation. i.e. further contraints upon an existing archetype. It is entirely appropriate to do so at archetype because Birth weight although clearly inheriting from Body weight, is itself a universal concept with quite specific and univerasally accepted contraints, not variant by speciality, locality or other context. I suspect there will be few instances of this sort of specialisation 2. Semi-abstracted archetypes e.g the NHS specialisations of Inspection and Palpation for different organs or systems e.g. Paplation-External_Ear or laboratory results In these cases, this approach allows generic 'first -principles' of clinical examination to be inherited to the specialised archetype e.g site. appearance, tenderness, likely to be common features of all examinations. It also allows the slot constraint mechanism to use the IS-A relationship to simplify acrchetype slot definitions at both archetype amd template level. I think we will run into trouble if we try to over-abstract and end up with long chains of specialisations but it is useful if restricted to one or two levels. 3. "Archetypes express what can be maximally documented about a topic" Agreed but the scope of the topic is not always completely clear especially around research requirements or in semi-clinical settings. A good example was raised at Alkmaar, of an adverse drug reaction form used in the context of clinical drug trials. Although the existing 'clinical' ADR archetype was almost acceptable, the requirements of data capture for drug trial purposes were subtly different in some aspects and not appropriate in a service delivery context. Specialisation of the clinical ADR archetype allows data to flow between the clinical setting and drug trial setting, without clinically inappropriate concepts being modelled in the parent. A similar scenario exists with research requirements where there are clear advantages to integrating research data to the EHR especially when the research starts to become accepted and starts to from part of service delivery , perhaps only locally at first. Specialisation allows 'unstable' research requirements to be modelled consistently with accepted archetypes with the expectation that if the 'new' becomes 'current' practice, the specialised elements will be promoted to the parent for universal use. Ian -- Dr Ian McNicoll office +44(0)141 560 4657 fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll Consultant - Ocean Informatics ian.mcnicoll at oceaninformatics.com Consultant - IRIS GP Accounts Member of BCS Primary Health Care Specialist Group ? http://www.phcsg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20071216/0373133c/attachment.html>
