Ian, It is fore most a matter of principle. The question to answer is where are the boundary lines between the different layers of the Semantic Stack. Feel free to blur this anyway you like.
I?m a firm believer that we must prevent problems in the future. The RM must be stable and must NOT contain any semantic notions. It must deal with lego-ethical things of storing, retrieving, exchange, etc. All the health specific semantics have to be dealt with in the archetype layer. And the set of standardised super-archetypes we use to specialise all other from. The whole business of taking care of the full semantics is to fluid at this point in time to be frozen in the RM. Gerard Gerard Freriks +31 620347088 gfrer at luna.nl On 18 feb. 2014, at 13:11, Ian McNicoll <ian.mcnicoll at gmail.com> wrote: > 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 > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140219/e3bf8d27/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140219/e3bf8d27/attachment-0001.asc>
