Hi Gerard, Good question. The value is not in the classification but in the attributes provided by the class. These save me some work as a modeller, should help the developer optimise some system aspects optimally (e.g by knowing that every ACTION archetype inherits a time and status that can be optimised for querying).
The first thing to say is that I do not see a particularly clear distinction between 'classes' modelled in a Reference model and 'top-level' i.e rigid patterns modelled in archetypes. In both cases you are providing modellers with some fixed attributes which are inherited by child archetypes. I am going to use Contsys as an example since this is alternative example of where the modellers have introduced specific classes/top-level patterns to reduce variability and enhance computability. IMO it does not really practically matter whether the Contsys 'Assessed Condition' is modelled in UML as part of the RM or provided as a 'reference archetype' sitting on top of a leaner RM. In both cases, if I want to adhere to the ContSys model, I have to inherit from 'Assessed Condition'. That puts severe constraints on the way that 'Assessed Condition' develops over time. It must remain very stable and carefully managed whether an RM construct or a top-level archetype. So whilst the full-blown generic ENTRY has value, both openEHR and Contsys do offer semi-rigid top-level patterns either via RM or 'reference archetypes'. In fact 'onotologically' there is a pretty close match between the ContSys 'Entry' models and openEHR Entry sub-classes AssessedCondition = EVALUATION Observed/PerceivedCondition = OBSERVATION Activity = ACTION which is unsurprising since both work from the same 'clinical process model'. If we accept that there is some utility in establishing these 'top-level patterns', we are inevitably going to run into use-cases where it is unclear if an ENTRY is an Observation or Evaluation but equally where it is unclear if a Condition is Assessed or Observed (smoking or housing summary being a prime example), or a least where there is variable interpretation. In most case this mixed or muddled classification is not at all important for querying purposes. I am not aware of any situations where I want to query for Observations. I want to query for 'Smoking Summary'., If I happened to model it as an Observation I would get the 'observation time' as part of the RM (or top-levle archetype). If I modelled it as an Evaluation, I would have to create a date recorded/verified' node explicitly in the archetype. So t value of the Classes/top-level archetypes are in the attributes that child archetypes can inherit, saving modelling effort and applying some consistency which can be exploited by developers, but there is little value in the classification per-se, other than as a guide. We do not query on archetype ENTRY sub-classes. Ian On 17 February 2014 23:50, Gerard Freriks <gfrer at luna.nl> wrote: > Ian, > > Can you answer the question: > When 'formal classifications' are unimportant, what is the use of such > classifications? > > we get caught up on the > philosophy and do not focus on the utility > > > Caring for the correct meaning is at the same time caring for utility. > It is not a philosophical issue. > Although some philosophical notions, > and linguistic ones > are helpful. > > Practicalities, translated as 'corners quickly cut', 'quick fixes', > look nice in the short run. > But how about the long(er) run? > > Gerard Freriks > +31 620347088 > gfrer at luna.nl > > On 17 feb. 2014, at 23:17, Ian McNicoll <ian.mcnicoll at gmail.com> wrote: > > Hi Bert, > > I think the problem here is that many people get hung up on the idea > of the ENTRY classes being a formal classification upon which some > sort of abstract computing will take place e.g. query for all > OBSERVATIONS but not EVALUATIONS. i.e. we get caught up on the > philosophy and do not focus on the utility. In other words if I > weirdly decide to make problem/diagnosis an ADMIN_ENTRY nothing will > be lost computationally. > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com ian at mcmi.co.uk Clinical Analyst Ocean Informatics Honorary Senior Research Associate, CHIME, University College London openEHR Archetype Editorial Group Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland
