# Templates - should we record which are used? **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2005-10-20 07:55 UTC **Views:** 10 **Replies:** 14 **URL:** https://discourse.openehr.org/t/templates-should-we-record-which-are-used/14513 --- ## Post #1 by @Sam Dear All, We have been discussing the issue of templates and whether we keep an identifier of a template in the data. My concern has been that this ID might be seen as an absolute constraint on the data, whereas the precedence of constraint must be: 1. The data must conform to the reference model 1. The data must conform to the archetypes 1. The data must be complete 1. The template can be invoked to ease data entry. What this means is that when data is already present, even if it does not conform to a template (which may have been used as a guide when entering data) it must be allowed. Clearly an application may restrict data entry to the template (this is an application issue) but it cannot impose a template on data already gathered. Keeping a template identifier in the EHR is then a statement only that a template of some sort was used in creating the data. This template may be in a form that is generally available (eg ADL) or a specific local template implementation - there is no need to use a generalisable form of template within the openEHR framework - though it has advantages. Having said that, it is clear that it may be useful and I would suggest that we consider an optional string attribute at the composition level that allows recording the id of a template used to form the composition. What do others think? Cheers, Sam - If you have any questions about using this list, please send a message to d.lloyd@openehr.org --- ## Post #2 by @christian.heller Dear Sam, > We have been discussing the issue of templates and whether we keep an > identifier of a template in the data\. My concern has been that this ID > might be seen as an absolute constraint on the data, whereas the precedence > of constraint must be: knowledge models \(reference models as existent in memory\) do NOT need to hold a link to the knowledge template \(archetype\) they were created \(instantiated\) from at all\. A knowledge model is a clone of a knowledge template\. The template merely delivers the initial values, not more\. > The data must conform to the reference model > The data must conform to the archetypes > The data must be complete > The template can be invoked to ease data entry\. You have to put all constraints into the runtime \(reference\) model, so that the model does not have to refer to its original template anymore\! Christian --- ## Post #3 by @thomas.beale Christian Heller wrote: > Dear Sam, > >> We have been discussing the issue of templates and whether we keep an >> identifier of a template in the data\. My concern has been that this ID >> might be seen as an absolute constraint on the data, whereas the precedence >> of constraint must be: >>    > knowledge models \(reference models as existent in memory\) do NOT need > to hold a link to the knowledge template \(archetype\) they were created > \(instantiated\) from at all\. > > A knowledge model is a clone of a knowledge template\. > The template merely delivers the initial values, not more\. > Hi Christian, well, that is one design approach, but it is not the one that we use in openEHR\. In openEHR, the archetypes are seen as part of the "ontology of information" \(distinct from ontologies of the "real world" like snomed\-ct etc\)\. We use them extensively in their own right\. We don't repeat all the archetype defnition informatoin in the actual data because a\) it would double the size of the data, while making it harder to compute with; b\) the persistent form of the data is not necessarily the desired persistence form of the archetypes \(in fact, it certainly isn't\.\.\.\) and c\) we want to make the data comprehensible to systems and users not using archetypes\. >> The data must conform to the reference model >> The data must conform to the archetypes >> The data must be complete >> The template can be invoked to ease data entry\. >>    > You have to put all constraints into the runtime \(reference\) model, > so that the model does not have to refer to its original template anymore\! > again, that is a valid desing approach, but we don't use it; we find it is much clearer to have separated data and archetypes\. \- thomas beale --- ## Post #4 by @christian.heller Hi Thomas, > well, that is one design approach, but it is not the one that we use in > openEHR\. In openEHR, the archetypes are seen as part of the "ontology of > information" \(distinct from ontologies of the "real world" like > snomed\-ct etc\)\. We use them extensively in their own right\. We don't I thought archetypes are the place to store expert/domain knowledge and the reference information model provided the structure that instances of archetypes have at runtime, in memory? What is the difference between the "ontology of information" and the "ontologies of the real world"? Could you give a short example for each? \(What you say sounds like medical domain knowledge were solely stored in terminologies like snomed\.\) > repeat all the archetype defnition informatoin in the actual data > because a\) it would double the size of the data, while making it harder True, the size of knowledge models would be larger if all constraints were stored in each of them, but they would be much more flexible and independent of types\. This is the deal: More flexibility and less dependencies or traditional type\-based programming\. If you make your knowledge models dependent on their corresponding knowledge template, then what you do is another form of type\-based programming\. As is known from scripting languages, typeless programming is much more flexible\. > to compute with; b\) the persistent form of the data is not necessarily > the desired persistence form of the archetypes \(in fact, it certainly Why shouldn't the archetype structure be the ideal way to make domain data persistent, too? If the archetype structure were general enough to represent any kind of knowledge, why shouldn't it be possible to make data persistent in this general structure? That for the past decades most of the world is using relational databases doesn't mean that for the next thousand years we have to continue to do so\. I am convinced that there are better ways to store knowledge\. Object\-orientation is just one step, but not sufficient\. > isn't\.\.\.\) and c\) we want to make the data comprehensible to systems and > users not using archetypes\. I don't see any reason why data should not be as well understandable as archetypes shall be\. I don't say you should give up archetypes; they are important to serve as initial knowledge template\. > >You have to put all constraints into the runtime \(reference\) model, > >so that the model does not have to refer to its original template anymore\! > > again, that is a valid desing approach, but we don't use it; we find it > is much clearer to have separated data and archetypes\. What we need, in my opinion, is some kind of universal runtime type \(knowledge structure/ schema\), which is able to represent any kind of knowledge\. Then the difference between knowledge templates \(archetypes\) and knowledge models \(their instances\) vanishes, because runtime models are represented in a general way, similar to their templates\. Christian --- ## Post #5 by @Sam Christian I think this conversation needs to be off-line as it is more philosophical and feels like lets start all over again. We do need to be able to justify the openEHR approach but not on this technical list. I am very interested in an informed critique of the openEHR approach if you read our work and come up with different approaches. Cheers, Sam Christian Heller wrote: > ``` > Hi Thomas, > > > ``` > > > ``` > > well, that is one design approach, but it is not the one that we use in > > openEHR. In openEHR, the archetypes are seen as part of the "ontology of > > information" (distinct from ontologies of the "real world" like > > snomed-ct etc). We use them extensively in their own right. We don't > > > > ``` > > ``` > > I thought archetypes are the place to store expert/domain knowledge > and the reference information model provided the structure that > instances of archetypes have at runtime, in memory? > > What is the difference between the "ontology of information" and the > "ontologies of the real world"? Could you give a short example for each? > (What you say sounds like medical domain knowledge were solely stored > in terminologies like snomed.) > > > ``` > > > ``` > > repeat all the archetype defnition informatoin in the actual data > > because a) it would double the size of the data, while making it harder > > > > ``` > > ``` > > True, the size of knowledge models would be larger if all constraints > were stored in each of them, but they would be much more flexible and > independent of types. This is the deal: More flexibility and less > dependencies or traditional type-based programming. If you make your > knowledge models dependent on their corresponding knowledge template, > then what you do is another form of type-based programming. As is known > from scripting languages, typeless programming is much more flexible. > > > ``` > > > ``` > > to compute with; b) the persistent form of the data is not necessarily > > the desired persistence form of the archetypes (in fact, it certainly > > > > ``` > > ``` > > Why shouldn't the archetype structure be the ideal way to make domain > data persistent, too? If the archetype structure were general enough > to represent any kind of knowledge, why shouldn't it be possible to > make data persistent in this general structure? > > That for the past decades most of the world is using relational databases > doesn't mean that for the next thousand years we have to continue to do so. > I am convinced that there are better ways to store knowledge. > Object-orientation is just one step, but not sufficient. > > > ``` > > > ``` > > isn't...) and c) we want to make the data comprehensible to systems and > > users not using archetypes. > > > > ``` > > ``` > > I don't see any reason why data should not be as well understandable > as archetypes shall be. > > I don't say you should give up archetypes; they are important to serve > as initial knowledge template. > > > ``` > > > > ``` > > > You have to put all constraints into the runtime (reference) model, > > > so that the model does not have to refer to its original template anymore! > > > > > > ``` > > > > ``` > > again, that is a valid desing approach, but we don't use it; we find it > > is much clearer to have separated data and archetypes. > > > > ``` > > ``` > > What we need, in my opinion, is some kind of universal runtime type > (knowledge structure/ schema), which is able to represent any kind of > knowledge. Then the difference between knowledge templates (archetypes) > and knowledge models (their instances) vanishes, because runtime models > are represented in a general way, similar to their templates. > > Christian > - > If you have any questions about using this list, > please send a message to [d.lloyd@openehr.org](mailto:d.lloyd@openehr.org) > > > ``` - If you have any questions about using this list, please send a message to d.lloyd@openehr.org --- ## Post #6 by @christian.heller > I think this conversation needs to be off\-line as it is more > philosophical and feels like lets start all over again\. We do need > to be able to justify the openEHR approach but not on this technical > list\. I am very interested in an informed critique of the openEHR > approach if you read our work and come up with different approaches\. O\.k\., agreed\. Just mentioned these things cause you asked for opinions on templates etc\. I will now try to write an article about my ideas, to publish it in the next few months \(after the usual game of "evaluation" etc\.\)\. I will send a short note to this list when it is done\. Also, I will try to include some informed critique on OpenEHR into the work I am currently writing and will inform you \(autumn 2006?\)\. Regards, Christian --- ## Post #7 by @christian.heller Hi Thomas, taking the risk of being too philosophical, I reply to the list anyway\. > In an ontology of information we might define \(say, with an archetype\) a > structured model of "systemic arterial blood pressure measurement"\. This > is a model of the information captured during the measuring of BP in the > usual way; it would include systolic, diastolic, and a way to record > patient position, cuff size and instrument type\. > > In an ontology of reality, we might define "blood pressure" as a > concept; in this ontology, the model expresses things like BP being a > specialisation of a pressure in a vessel \(blood in a blood vessel\); with > 5 identified phases etc etc etc\. This model is likely to be a\) quite > complex, and b\) the details found in the archetype model might be there, > but will be buried in a large model which shows what blood pressure > really is\. > > Archetypes in general are models of information and belong to an > ontology of information; "ontologies of the real world" on the other > hand describe kinds or categories of actual reality \- the same > information as would be found in a medical, biochemistry and anatomy > textbook\. That was well\-explained, thanks\! Nevertheless, I think that these ontology definitions are not that important if talking about knowledge modelling in general\. Every knowledge model \(I use "model" to not conflict with different definitions of "template"\) is a subjective abstraction of the real world anyway\. It does not matter whether the abstraction is simplified a lot \(like an ontology of information\) for a specific context or less \(ontology of the real world\) \-\- it is always an abstract model and as such simplified\. Nobody can model the real world in complete anyway\. To me, ontology of information as you use it in form of archetypes sounds more useful than the other kind\. The ontology of the real world sounds like what terminologies want to achieve, right? I guess you had some difference of opinion with terminology people and therefore introduced those two differing definitions\. If you use these two kinds of ontology to distinguish between archetypes \(ontology of information\) and terminologies \(ontology of the real world\), then why not? This is just a question of definition\. Anyway, I don't see a big difference between the principles behind the two\. > well, typeless programming is one approach to software programming\. > Personally I don't believe in it, and neither do many others\. I realise > of course that there are some who do, so I am not going to claim to have > the absolute truth on this issue\. But just consider this: almost > everyone who writes in a typeless language ends up using variable names > like intSectionCount and boolPersistenceFlag etc \- where the intended > types are built into the variable names\. I am not exactly talking about typeless programming but about a universal kind of type\. I did and still do appreciate your first OpenEHR design paper back in 2001, since it opened my eyes\. In it, you described how to move from a single model, across a semi\-structured model on to a hierarchical knowledge representation and, as consequence, the dual model approach\. Of course, the composite design pattern \(as used by the hierarchical knowledge representation\) was not sufficient to represent knowledge of any kind\. But it was the right starting point to extend it to a universal kind of type\. Further research would have been/ would be necessary\. Unfortunately, you seemed to leave this path of research in the following years and sticked with OOP instead\. > I can't say I have felt any lack of flexibility in using typed systems \- > I think flexibility or lack of is really a result of good or bad design\. > The kind of design we use \- based on archetypes as an entirely separate > level of modelling is extremely flexible, but the underlying object > model is still type\-based\. I do not criticise the archetype approach\. I do criticise the underlying object model\. I think you could try to reduce this model to just one universal type\. Put type information and inheritance, if wanted, into the archetypes\. Separate attributes and methods into their own archetypes\. Then you don't need OOP anymore\. Reflective techniques that you use \(following Fowler's analysis patterns\) to reference archetypes bring with a lot of bidirectional dependencies and problems\. Use unidirectional dependencies; the "object" model \(without OOP rather system\-level/runtime model\) knows about the archetypes, not the other way\. Of course, some changes in the archetypes would be necessary, too\. I know this sounds a bit crazy and like a lot of work, much what has been achieved would have to be thrown away; but why not think about it? > >Why shouldn't the archetype structure be the ideal way to make domain > >data persistent, too? If the archetype structure were general enough > >to represent any kind of knowledge, why shouldn't it be possible to > >make data persistent in this general structure? > > > We are not trying to make the archetypes so general \- they have a very > defined purpose, and it does not include trying to represent the same > sort of information as snomed or Galen \- i\.e\. models of reality\. I fully agree with your approach to archetypes\. All kinds of knowledge models are made to serve a special purpose/ application\. Terminologies are very subjective ways of sorting millions of terms and one could find a million ways to sort those millions of terms differently\. It always depends on the intended purpose/ planned application\. What I wanted to say above was not about terminologies etc\. I suggested to make archetypes general in a way that they could represent not only domain knowledge, but also graphical/ textual/ web user interfaces, algorithms etc\. Of course, you would have to separate attributes and methods \(algorithms\), in order to represent them independently\. > >That for the past decades most of the world is using relational databases > >doesn't mean that for the next thousand years we have to continue to do so\. > >I am convinced that there are better ways to store knowledge\. > >Object\-orientation is just one step, but not sufficient\. > > > well, I agree there\. Archetypes are constraint models, which I consider > an advance on object\-orientation\. The main advantage, to me, are not so much the constraints, but the distinction between knowledge \(archetypes\) and system control \(object model\)\. If we want to improve OOP, then let's not build on it\. Have you ever thought about implementing the "object model" in a procedural language? If your knowledge resides in archetypes anyway, why still using OOP? > >What we need, in my opinion, is some kind of universal runtime type > >\(knowledge structure/ schema\), which is able to represent any kind of > >knowledge\. Then the difference between knowledge templates \(archetypes\) > >and knowledge models \(their instances\) vanishes, because runtime models > >are represented in a general way, similar to their templates\. > > > well, maybe this could happen in the future, I don't know\. But we are > already so far ahead of the standard way of computing that it has become > imperative to put a stake in the sand and work with the approach we have > created so far\. The first release of OpenEHR will be an important step\. Go for it\! I am just philosophising about version 3 or 4 \.\.\. Christian --- ## Post #8 by @Sam Christian I am sure I did not understand all of what you have said....but it seems to me you are suggesting that the dual model approach has a future beyond the current split of knowledge and OOP. This is an interesting idea. In fact I wrote the archetype editor before ADL was available - and much of the functionality of ADL was built around the need to get from the clinical to the current openEHR reference model. Inevitably this approach has tied the two worlds together in a particular manner. I have no doubt that there are other ways to express these clinical concepts and it is our wish that the archetypes have a life of their own and start to inform HL7 and other implementations. The match with the RIM and RMIM is not good and the links may have to be hard-coded - but they will still be more useful than lots of RMIMs in various languages. Thanks for the mind stretch - Sam Christian Heller wrote: > ``` > Hi Thomas, > > taking the risk of being too philosophical, I reply to the list anyway. > > > ``` > > > ``` > > In an ontology of information we might define (say, with an archetype) a > > structured model of "systemic arterial blood pressure measurement". This > > is a model of the information captured during the measuring of BP in the > > usual way; it would include systolic, diastolic, and a way to record > > patient position, cuff size and instrument type. > > > > In an ontology of reality, we might define "blood pressure" as a > > concept; in this ontology, the model expresses things like BP being a > > specialisation of a pressure in a vessel (blood in a blood vessel); with > > 5 identified phases etc etc etc. This model is likely to be a) quite > > complex, and b) the details found in the archetype model might be there, > > but will be buried in a large model which shows what blood pressure > > really is. > > > > Archetypes in general are models of information and belong to an > > ontology of information; "ontologies of the real world" on the other > > hand describe kinds or categories of actual reality - the same > > information as would be found in a medical, biochemistry and anatomy > > textbook. > > > > ``` > > ``` > > That was well-explained, thanks! > > Nevertheless, I think that these ontology definitions are not that > important if talking about knowledge modelling in general. > Every knowledge model (I use "model" to not conflict with different > definitions of "template") is a subjective abstraction of the real > world anyway. It does not matter whether the abstraction is simplified > a lot (like an ontology of information) for a specific context or less > (ontology of the real world) -- it is always an abstract model and as > such simplified. Nobody can model the real world in complete anyway. > > To me, ontology of information as you use it in form of archetypes > sounds more useful than the other kind. The ontology of the real world > sounds like what terminologies want to achieve, right? > I guess you had some difference of opinion with terminology people and > therefore introduced those two differing definitions. > If you use these two kinds of ontology to distinguish between archetypes > (ontology of information) and terminologies (ontology of the real world), > then why not? This is just a question of definition. Anyway, I don't see > a big difference between the principles behind the two. > > > ``` > > > ``` > > well, typeless programming is one approach to software programming. > > Personally I don't believe in it, and neither do many others. I realise > > of course that there are some who do, so I am not going to claim to have > > the absolute truth on this issue. But just consider this: almost > > everyone who writes in a typeless language ends up using variable names > > like intSectionCount and boolPersistenceFlag etc - where the intended > > types are built into the variable names. > > > > ``` > > ``` > > I am not exactly talking about typeless programming but about a > universal kind of type. I did and still do appreciate your first > OpenEHR design paper back in 2001, since it opened my eyes. In it, > you described how to move from a single model, across a semi-structured > model on to a hierarchical knowledge representation and, as consequence, > the dual model approach. Of course, the composite design pattern (as > used by the hierarchical knowledge representation) was not sufficient > to represent knowledge of any kind. But it was the right starting point > to extend it to a universal kind of type. Further research would have > been/ would be necessary. Unfortunately, you seemed to leave this path > of research in the following years and sticked with OOP instead. > > > ``` > > > ``` > > I can't say I have felt any lack of flexibility in using typed systems - > > I think flexibility or lack of is really a result of good or bad design. > > The kind of design we use - based on archetypes as an entirely separate > > level of modelling is extremely flexible, but the underlying object > > model is still type-based. > > > > ``` > > ``` > > I do not criticise the archetype approach. I do criticise the underlying > object model. I think you could try to reduce this model to just one > universal type. Put type information and inheritance, if wanted, into > the archetypes. Separate attributes and methods into their own archetypes. > Then you don't need OOP anymore. Reflective techniques that you use > (following Fowler's analysis patterns) to reference archetypes bring > with a lot of bidirectional dependencies and problems. Use unidirectional > dependencies; the "object" model (without OOP rather system-level/runtime > model) knows about the archetypes, not the other way. > Of course, some changes in the archetypes would be necessary, too. > > I know this sounds a bit crazy and like a lot of work, much what has > been achieved would have to be thrown away; but why not think about it? > > > ``` > > > > ``` > > > Why shouldn't the archetype structure be the ideal way to make domain > > > data persistent, too? If the archetype structure were general enough > > > to represent any kind of knowledge, why shouldn't it be possible to > > > make data persistent in this general structure? > > > > > > > > > ``` > > > > ``` > > We are not trying to make the archetypes so general - they have a very > > defined purpose, and it does not include trying to represent the same > > sort of information as snomed or Galen - i.e. models of reality. > > > > ``` > > ``` > > I fully agree with your approach to archetypes. All kinds of knowledge > models are made to serve a special purpose/ application. Terminologies > are very subjective ways of sorting millions of terms and one could > find a million ways to sort those millions of terms differently. It > always depends on the intended purpose/ planned application. > > What I wanted to say above was not about terminologies etc. > I suggested to make archetypes general in a way that they could > represent not only domain knowledge, but also graphical/ textual/ web > user interfaces, algorithms etc. Of course, you would have to separate > attributes and methods (algorithms), in order to represent them > independently. > > > ``` > > > > ``` > > > That for the past decades most of the world is using relational databases > > > doesn't mean that for the next thousand years we have to continue to do so. > > > I am convinced that there are better ways to store knowledge. > > > Object-orientation is just one step, but not sufficient. > > > > > > > > > ``` > > > > ``` > > well, I agree there. Archetypes are constraint models, which I consider > > an advance on object-orientation. > > > > ``` > > ``` > > The main advantage, to me, are not so much the constraints, but the > distinction between knowledge (archetypes) and system control > (object model). If we want to improve OOP, then let's not build on it. > Have you ever thought about implementing the "object model" in a > procedural language? If your knowledge resides in archetypes anyway, > why still using OOP? > > > ``` > > > > ``` > > > What we need, in my opinion, is some kind of universal runtime type > > > (knowledge structure/ schema), which is able to represent any kind of > > > knowledge. Then the difference between knowledge templates (archetypes) > > > and knowledge models (their instances) vanishes, because runtime models > > > are represented in a general way, similar to their templates. > > > > > > > > > ``` > > > > ``` > > well, maybe this could happen in the future, I don't know. But we are > > already so far ahead of the standard way of computing that it has become > > imperative to put a stake in the sand and work with the approach we have > > created so far. > > > > ``` > > ``` > > The first release of OpenEHR will be an important step. Go for it! > I am just philosophising about version 3 or 4 ... > > Christian > - > If you have any questions about using this list, > please send a message to [d.lloyd@openehr.org](mailto:d.lloyd@openehr.org) > > > ``` - If you have any questions about using this list, please send a message to d.lloyd@openehr.org --- ## Post #9 by @system Hi Christian, I try to digest what you have said. See in the text. Gerard -- -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252 544896 M: +31 654 792800 > Nevertheless, I think that these ontology definitions are not that > important if talking about knowledge modelling in general. > Every knowledge model (I use "model" to not conflict with different > definitions of "template") is a subjective abstraction of the real > world anyway. It does not matter whether the abstraction is simplified > a lot (like an ontology of information) for a specific context or less > (ontology of the real world) -- it is always an abstract model and as > such simplified. Nobody can model the real world in complete anyway. 1- The real world. Very complex and we don't know all about it. Both patient and healthcare provider operate in this world. This is where illness, and physical signs, molecules, atoms do their thing. 2- The model of the real world. People all have a simplified model of this real world. This is based on the knowledge and expertise of people. The knowledge and expertise is ever growing. This knowledge and expertise is formed using a system of concepts. Some of these are completely shared, others partially, between communicating parties. Concepts are defined within a context and with a purpose. People use various collections of concepts depending on context and purpose. The system of concepts is known as Ontology or model of the real world. 3- Registration/documentation of the healthcare process This takes place in the real world using real world events using real world physical objects. Each healthcare provider has the need or obligation to record what he has done while treating patients with problems, symptoms. The healthcare process from the documentation point of view (context) is the collection of facts of what is heard, seen, felt, smelled, thought during this healthcare process. Data is collected and documented. On the basis of expertise and knowledge the healthcare provider (professional) forms a professional opinion supported by a series of collected data. The production of a professional opinion about the real world phenomena (see bullit number 1) is from the registration/documentation point of view one important function of any healthcare professional. In addition he performs/orders certain procedures that need to be registered and documented. The documentation of collected real world facts and real world procedures plus the production of the professional opinion and some orders or the execution of procedures is what gets done and documented. All the facts are expressed by the patient using his own model of the real world. (bullit number 2) and subsequently interpreted by the healthcare professional using his own bullit point number 2 model. And then it gets documented in a registrative system (paper and pencil or computers) using a collection of concepts designed for this purpose. e.g. Archetypes. For this we need an Archetype ontology (aka model of information, domain information model) as an abstract model that is very much simplified and distorted as compared with the models of bullet points 1 and 2. Many of the problems we have dealing with information in computer systems is that the same concept is used in several contexts/ontologies and ends up in a "universal" archetype that gets instantiated and becomes a non-universal. This state change confuses many systems (and persons). An other confusion is the fact that at one point something is a professional opinion and after transfer to the next healthcare provider a fact and no longer the professional opinion. What I mean is: a blood sample is drawn. It is very physical and is part of the bullet point 1 world. This fact is documented as facts (data) using concepts from bullet point 3. On the basis of a sub-set of the bullet point 2 model the facts are interpreted and end up in the professional opinion. This opinion is described in terms of the bullet point 3 ontology. But when sent to an other healthcare provider this opinion becomes a fact in his system. > To me, ontology of information as you use it in form of archetypes > sounds more useful than the other kind. The ontology of the real world > sounds like what terminologies want to achieve, right? We need those terminologies. They are the words (codes) used the express concepts. Archetypes are the constructs of "what can or must be said/documented" in the course of the provision of healthcare. > I guess you had some difference of opinion with terminology people and > therefore introduced those two differing definitions. > If you use these two kinds of ontology to distinguish between archetypes > (ontology of information) and terminologies (ontology of the real world), > then why not? This is just a question of definition. Anyway, I don't see > a big difference between the principles behind the two. They are never the same. Context/purpose make them different. What they describe is different and not the same. But they overlap because they use the same words/codes to define the concepts used. > I am not exactly talking about typeless programming but about a > universal kind of type Universal kind of type? What do you mean? In ontology terms used by Barry Smith universal is meant to denote, as I understand and translate it, the facts/items that describe an object in the general sense. Not this particular object (say chair) but those objects in general (all types of chairs). In a way archetypes are universals themselves. And describe of what could be said in a particular context in general. When instantiated (as template) and filled they describe a fully defined particular context at this time, place, author, patient, etc. But the archetypes make use of concepts that don't have to be universals. > . I did and still do appreciate your first > OpenEHR design paper back in 2001, since it opened my eyes. Could you elaborate on this? > In it, > you described how to move from a single model, across a semi-structured > model on to a hierarchical knowledge representation and, as consequence, > the dual model approach. Of course, the composite design pattern (as > used by the hierarchical knowledge representation) was not sufficient > to represent knowledge of any kind. But it was the right starting point > to extend it to a universal kind of type. Further research would have > been/ would be necessary. Unfortunately, you seemed to leave this path > of research in the following years and sticked with OOP instead. > > I do not criticise the archetype approach. I do criticise the underlying > object model. I think you could try to reduce this model to just one > universal type. Put type information and inheritance, if wanted, into > the archetypes. Separate attributes and methods into their own archetypes. > Then you don't need OOP anymore. Reflective techniques that you use > (following Fowler's analysis patterns) to reference archetypes bring > with a lot of bidirectional dependencies and problems. Could you provide examples, so I can understand what you mean? What do you mean by OOP in this context? P stands for Programming, isn't it? And what have programs to do with the definition of things/concepts? > Use unidirectional > dependencies; the "object" model (without OOP rather system-level/runtime > model) knows about the archetypes, not the other way. > Of course, some changes in the archetypes would be necessary, too. Can I understand that the "object model" is that what gets instantiated in a computer system at run time? And that the "information Model" (aka Archetype) defines several aspects: a- information (its invariants, etc) b- methods and c- presentation So far the Archetypes in OpenEHR and CEN describe -a-. If what I understand is what you mean, then I agree fully that the future of OpenEHR and CEN is to explore in future versions the definition, expression, exchange of aspects b and c. B is needed to define protocols. C is needed to handle the aspect of presentation that conveys semantic information in its own right. > I know this sounds a bit crazy and like a lot of work, much what has > been achieved would have to be thrown away; but why not think about it? > > I fully agree with your approach to archetypes. All kinds of knowledge > models are made to serve a special purpose/ application. Terminologies > are very subjective ways of sorting millions of terms and one could > find a million ways to sort those millions of terms differently. It > always depends on the intended purpose/ planned application. > > What I wanted to say above was not about terminologies etc. > I suggested to make archetypes general in a way that they could > represent not only domain knowledge, but also graphical/ textual/ web > user interfaces, algorithms etc. Of course, you would have to separate > attributes and methods (algorithms), in order to represent them > independently. > > The main advantage, to me, are not so much the constraints, but the > distinction between knowledge (archetypes) and system control > (object model). If we want to improve OOP, then let's not build on it. > Have you ever thought about implementing the "object model" in a > procedural language? If your knowledge resides in archetypes anyway, > why still using OOP? > > The first release of OpenEHR will be an important step. Go for it! > I am just philosophising about version 3 or 4 ... Good. Thanks. --- ## Post #10 by @Dr_LONJON_Roger Bonjour, Votre message \(renvoi automatique \) bi lingue \.\. sezmble indiquer que vous êtes un peu francophone \( et teamlog ?\) Je suis à l'initiative d'un projet visant à mettre sur le site openehr\.org \( en accord avec T Baele\) une version en français des documents qui sont surtout en anglais \. Je fais appel à toutes les competences et bonne volonté , a titre bénévole , susceptible de donner un peu de leur temps pour realiser une traduction française \.\. Si vous maitrisez parfaitement l'anglais et le français \.\. vous êtes la perle rare \.\. que je recherche \.\. Seriez vous interessée ? Bien cordialement Dr R LONJON Selon Sandrine VILLAEYS <svi@teamlog\.com>: --- ## Post #11 by @thomas.beale For the non French speakers here \(most of the group\) \- I will quickly translate so that no\-one feels uncomfortable with stuff they can't read on this list\! Dr Lonjon is simply looking for some help amongst francophone openEHR members who could help with translating the openEHR documents into french\. \(for the francophones reading this, probably best to organise such things with Dr Lonjon directly, or stick to english as far as possible in this list; thanks\)\. \- thomas beale Dr LONJON Roger wrote: --- ## Post #12 by @thomas.beale Christian Heller wrote: > Hi Thomas, > > taking the risk of being too philosophical, I reply to the list anyway\. > you took the risk and you were;\-\) But that's ok, we like philosophy here\.\.\. to briefly reply/paraphrase your remarks: you are suggesting that the current split between the reference model in openEHR and archetypes is nothing special, why not just have an object model of 1 or 2 classes representing 'thing', and do everything in archetypes? This is certainly theoretically possible \- you would probably want a few more types, basic data types and data structures are useful\. We have stayed with the split we have in openEHR because:     \* the world is not yet ready for having nothing at all in the software;     \* we still need software to do basic computing tasks like creating       data, storing it, querying it etc\. Most people's understanding of       that is based in an OO paradigm of classes and attributes\. I agree       that in the future we might be able to move onto systems where       everything is done in archeytpe processing, but the health       informatics world is not yet ready for that\. You only have to look       at models being built in CEN EN13606, HL7, IHE, ISO etc to see that\.     \* the part of the ontology that is in the reference model is that       part which people can agree is domain\-invariant, i\.e\. always has       the same meaning \(i\.e\. an Observation is an Observation is an       Observation, not matter what of\)\. This means they can safely write       software and create data and it will work in current technology,       even with no archetypes\. The archetypes layer is not invariant,       and is not meant to be\. So, one way of understanding the split is       as between the layers ontology that everyone can agree on as being       constant, and on layers that are diverse and variable\. So, in summary there is \(and has to be\) some pragmatism in what we are doing\.\.\. hope this helps\. \- thomas --- ## Post #13 by @Dr_LONJON_Roger Hi All, Thank you Thomas for the translation and explanations\!\!\! My message would not have to appear it on the list\.\.\.who is in English language It is a mistake\.\. \(of recipient\) I ask you to accept my apologies Dr LONJON Selon Thomas Beale <Thomas\.Beale@OceanInformatics\.biz>: --- ## Post #14 by @christian.heller Hi Gerard, > Many of the problems we have dealing with information in computer > systems is that the same concept is used in several contexts/ > ontologies and ends up in a "universal" archetype that gets > instantiated and becomes a non\-universal\. This state change confuses > many systems \(and persons\)\. I am talking about a universal \*schema\* \(structure\) for knowledge representation, not a universal archetype\. The schema, however, would be general enough to be able to represent any archetype\. Note: A schema delivers just the knowledge structure and is free of any domain knowledge; archetypes ideally contain domain knowledge only\. > > To me, ontology of information as you use it in form of archetypes > > sounds more useful than the other kind\. The ontology of the real world > > sounds like what terminologies want to achieve, right? > > We need those terminologies\. > They are the words \(codes\) used the express concepts\. O\.k\. I admit that I am still not clear with myself on this issue\. Currently, I don't consider myself proficient enough to further contribute to this discussion\. Need more time for reflection first\. \[archetypes and terminologies\] > They are never the same\. > Context/purpose make them different\. > What they describe is different and not the same\. > But they overlap because they use the same words/codes to define the > concepts used\. Yes, the terminology used in the contexts of archetypes/terminologies definitely does overlap\. But I am not sure if they really have to be treated separately or not\. As said before, I still need to reflect more on this topic and cannot/ will not further participate in its discussion\. > Universal kind of type? > What do you mean? More concrete, a universal schema \(type structure\)\. > In ontology terms used by Barry Smith universal is meant to denote, > as I understand and translate it, the facts/items that describe an > object in the general sense\. > Not this particular object \(say chair\) but those objects in general > \(all types of chairs\)\. > In a way archetypes are universals themselves\. And describe of what > could be said in a particular context in general\. When instantiated > \(as template\) and filled they describe a fully defined particular > context at this time, place, author, patient, etc\. > But the archetypes make use of concepts that don't have to be > universals\. I think we have a misunderstanding here\. Hearing "universal", you seem to think about elementary building blocks, while I was talking about a schema \(structure\) underlying all knowledge\. I did \*not\* mean archetypes or their contents or context etc\. > > \. I did and still do appreciate your first > > OpenEHR design paper back in 2001, since it opened my eyes\. > > Could you elaborate on this? I mentioned the three modelling approaches: single, semi\-structured and hierarchical knowledge representation\. For further details on these, please refer to Thomas' explanations in the referenced paper\. I believe that the last of these models \(composite pattern\) comes closest to the universal schema I was talking about\. Of course, it certainly is insufficient still and further research is needed\. > > I do not criticise the archetype approach\. I do criticise the > > underlying > > object model\. I think you could try to reduce this model to just one > > universal type\. Put type information and inheritance, if wanted, into > > the archetypes\. Separate attributes and methods into their own > > archetypes\. These are clear statements/ instructions\. > > Then you don't need OOP anymore\. Reflective techniques that you use > > \(following Fowler's analysis patterns\) to reference archetypes bring > > with a lot of bidirectional dependencies and problems\. > > Could you provide examples, so I can understand what you mean? See: Martin Fowler\. Analysis Patterns\. You will find two levels of software, a "knowledge level" and an "operational level" with bidirectional dependencies\. Also see: Frank Buschmann\. Pattern\-orientierte Softwarearchitektur\. You will find the "Reflection" pattern and illustrations of the bidirectional dependencies between its two \(or more\) levels\. Even Buschmann mentions the disadvantages of these dependencies\. > What do you mean by OOP in this context? > P stands for Programming, isn't it? Yes, "Object Oriented Programming"\. Sorry that I didn't write the full name\. I myself don't like unexplained abbreviations\. > And what have programs to do with the definition of things/concepts? Oh Jesus, that is getting to much\! One could write a whole book about this\. This whole list is about how to abstract things/ concepts in software/ programs\. I thought you knew about that\. > Can I understand that the "object model" is that what gets > instantiated in a computer system at run time? Yes\. Archetypes at design time\. Object model at runtime\. But you have to distinguish between the actual instances \(objects\) and the structure they have\. This often caused a knot in my mind, because one never knew exactly what was meant when talking about the object model or reference information model\. I believe the reference information model relates to the structure behind the object model\. But OpenEHR people should specify this\. \[I personally do call the three: 1 "Knowledge Template" \(design time\) 2 "Knowledge Model" \(runtime\) 3 "Knowledge Schema" \(research time\) But since there were conflicts with the usage of the term "template", so I sticked to OpenEHRs terms\.\] > And that the "information Model" \(aka Archetype\) defines several > aspects: > a\- information \(its invariants, etc\) > b\- methods > and > c\- presentation Yes\. > So far the Archetypes in OpenEHR and CEN describe \-a\-\. > > If what I understand is what you mean, then I agree fully that the > future of OpenEHR and CEN is to explore in future versions the > definition, expression, exchange of aspects b and c\. > B is needed to define protocols\. > C is needed to handle the aspect of presentation that conveys > semantic information in its own right\. Yes\. Christian --- ## Post #15 by @christian.heller Hi Thomas, > >taking the risk of being too philosophical, I reply to the list anyway\. > > > you took the risk and you were;\-\) But that's ok, we like philosophy here\.\.\. Sometimes it is hard to put all those thoughts into concrete terms\. Just trying to cross some borders that might limit our thinking \.\.\. > to briefly reply/paraphrase your remarks: you are suggesting that the > current split between the reference model in openEHR and archetypes is > nothing special, The split is special, because archetypes are flexible while traditional classes with attributes and methods hard\-wired in them are not\. > why not just have an object model of 1 or 2 classes > representing 'thing', and do everything in archetypes? Yes, that is about right\. But not everything should be done in archetypes, just everything that belongs to domain knowledge, to which also count user interfaces and workflows in my opinion\. > This is certainly > theoretically possible \- you would probably want a few more types, basic > data types and data structures are useful\. Not necessarily\. If you make the only remaining universal type a container which can emulate any other kinds of containers, then you do not need different types for data structures anymore\. \(I mentioned this about a year ago in this list, but somehow cannot find the list archive to reference my mail here\.\) > We have stayed with the split we have in openEHR because: \[\.\.\] This is plausible for now and I have to accept\. > So, in summary there is \(and has to be\) some pragmatism in what we are > doing\.\.\. I see and I agree\. So let's continue this dialogue when time has come\. Christian --- **Canonical:** https://discourse.openehr.org/t/templates-should-we-record-which-are-used/14513 **Original content:** https://discourse.openehr.org/t/templates-should-we-record-which-are-used/14513