Tim Cook wrote: > Hi P?ria, > > On Fri, 2008-07-04 at 14:18 +0200, P?ria Kashfi wrote: > >> Hi there, >> I feel the most important thing in developing suitable templates is to >> understand the openEHR reference model and its basic concepts very >> well and to be able to analyze the case and extract required >> information that may help finding proper archetype clues while >> designing. It may sounds simple at first glance but is a tedious >> task. >> > > I do not think that it is a requirement for knowledge workers to have a > deep understanding of the reference model. > > I believe (I hope) that one of the tenets of openEHR is to separate the > clinical element design (knowledge work) from the implementations > (software). > > * It is, but we need to be careful of what we mean by saying clinical people don't need to know the reference model. It is true that clinical people should not need to know the reference model in its role as software, i.e. all the functionality built into an implementation and so on. And there are large parts of the reference model that are of no interest to clinical people, e.g. most of the Support and Common models. However, the reference model also stands for something else - it functions as the base ontology of openEHR - and makes semantic commitments to certain kinds of Entries, data types, data structures and so on. This aspect of the reference model needs to be understood by everyone involved in openEHR. To take a concrete example: a clinician building an archetype who doesn't know that Observation takes care of representing a Historical time-series of samples won't know how to build an archetype for Apgar or rolling BP. Similarly, someone who does not realise that an Instruction is different from an Action won't understand how to build archetypes for orders and results. Someone who doesn't understand that there are 5 or so quantity data types might make the mistake of using the Quantity one for everything.
The semantics of the RM that need to be understood in this way probably constitute somewhat over 50% of the total classes and attributes. Probably we need this cut down version to be visible in some way, e.g. as an exported view from a UML tool. - thomas beale *
