Templates - should we record which are used?

[Sam Heard]

An HTML attachment was scrubbed...
URL: 

Templates - should we record which are used?

[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
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Templates - should we record which are used?

[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

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Templates - should we record which are used?

[Gerard Freriks]

Dear Sam,

When a Template is shared by to communicating parties we will have to  
record this in the EHR.
This is because this is the Information part of the "contract" the  
communicating parties have. It is one that pertains to their  
communications.
When the Template is used to store information I consider this a  
"contract" as well.

The Template either has an ID or is identified by the tree of  
constituting archetypes.

Gerard Freriks

-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO Quality of Life
Wassenaarseweg 56
Leiden

PostBox 2215
22301CE Leiden
The Netherlands

T: +31 71 5181388
M: +31 654 792800


On 20-okt-2005, at 9:55, Sam Heard wrote:

> 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:
> 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.
> 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
> -- 
> Dr. Sam Heard
> MBBS, FRACGP, MRCGP, DRCOG, FACHI
>
> CEO and Clinical Director
> Ocean Informatics Pty. Ltd.
> Adjunct Professor, Health Informatics, Central Queensland University
> Senior Visiting Research Fellow, CHIME, University College London
> Chair, Standards Australia, EHR Working Group (IT14-9-2)
> Ph: +61 (0)4 1783 8808
> Fx: +61 (0)8 8948 0215
>
> - If you have any questions about using this list, please send a  
> message to d.lloyd at openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 

Templates - should we record which are used?

[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
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Templates - should we record which are used?

[Sam Heard]

An HTML attachment was scrubbed...
URL: 

Templates - should we record which are used?

[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
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Templates - should we record which are used?

[Rong Chen]

Sam Heard wrote:
> 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
>2. The data must conform to the archetypes
>3. The data must be complete
>4. 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?

Sam,

I agree keeping template identification information in EHRs is useful. 
And it could be useful not only in Composition but also in other classes 
like Entry and Party level classes.

If so, maybe we should even consider to create a class Templated with 
all the details regarding usage of the template, e.g access control, and 
include it as optional attribute named "templateDetails" in root class 
Locatable so that Composition and other Locatable subclasses can get 
template support.

On the other hand, if Template is modeled as subclass of Archetype (it 
looks like a template is kind of specialized archetype) and TemplateID 
is subclassing ArchetypeID, we could very well stay with the current 
Locatable definition and have template support straight away.

Regards,

Rong


> 
> Cheers, Sam
> -- 
> 
> 
> Dr. Sam Heard
> MBBS, FRACGP, MRCGP, DRCOG, FACHI
> 
> CEO and Clinical Director
> Ocean Informatics Pty. Ltd.
> Adjunct Professor, Health Informatics, 
> Central Queensland University
> Senior Visiting Research Fellow, CHIME, University College London
> Chair, Standards Australia, EHR Working Group (IT14-9-2)
> /Ph: +61 (0)4 1783 8808/
> /Fx: +61 (0)8 8948 0215/
> 
> 
> - If you have any questions about using this list, please send a message 
> to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Templates - should we record which are used?

[Thomas Beale]

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?
>  
>

Hi Christian,
archetypes store a certain kind of domain knowledge only, see next point..

>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.)
>  
>
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.


>  
>
>>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.
>  
>
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 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.

>  
>
>>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?
>  
>
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.

>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.

>
>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 fa

Templates - should we record which are used?

[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?

Templates - should we record which are used?

[Gerard Freriks]

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


On 27-okt-2005, at 17:49, Christian Heller wrote:

> 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 ques

Templates - should we record which are used?

[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

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

AW: Templates - should we record which are used?

[christian.hel...@tuxtax.de]

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 e

AW: Templates - should we record which are used?

[christian.hel...@tuxtax.de]

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

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

AW: Templates - should we record which are used?

[Sandrine VILLAEYS]

Je suis en cong?s jusqu'au mercredi 2 novembre inclus.

I'm in vacation until the 2nd of November, 2005 included.

Sandrine Villaeys

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Archetypes and two-level modeling was: Templates - should we record which are used?

[Tim Cook]

Hi All,

An interesting conversation that, while deemed philosophical by some, is
really very pragmatic.  

A few weeks ago I said (on the openEHR Clinical list) I would write up
more details about the 'why' (I did) and others should choose this
approach to building clinical (or any other complex data) applications.
This thread has prompted me to do so now.

Christian's point of view is one that is widely held. There are problems
with this view/approach on many points.  Tom has expertly replied to
some of them below.  

I want to speak to the issue of 'information in context'. An electronic
health record is an information system about a person's physical,
mental, emotional well being at any one point in time as that well being
relates to the person's total 'known' physical and social environment.
All proper decisions regarding any prognosis and/or plan on any level is
based on information available at the time the decision is made.
Therefore it is of primary importance that all pieces of KNOWN AND
RECORDED information be able to be assembled as they relate to each
other with regard to time.  

That is the present tense challenge and most EMR/EHR applications can
meet that challenge.  However, problems begin to arise as time passes.
With the expected effective lifetime of an EHR easily exceeding 125
years we must anticipate that there will be huge changes in the
recording and delivery of this information during the lifetime of a
person's record.  Without a crystal ball to give me that future
knowledge I can look at recent history and reasonably expect similar
changes.  

One issue that is seen in information systems in general is that
schema's change.  Information models grow/mutate to meet the demands of
new knowledge and new expectations.  The way this issue is handled most
of the time is to either:

a) migrate the existing data in one 'upgrade' process so it will all run
under the new application version.

b) maintain the ability to read the old data but migrate it to the new
schema when it is accessed.

These approaches work well for many applications.  However, when it is
important to be able to look back at a point in time and see exactly
what a decision maker could see it should be obvious that you cannot
make changes to not only the existing data but the environment it was
recorded in (the context).  This is an especially important issue in
medic-legal situations as well as population health examination and
probably many other areas health research.  

By building an application using a reference model that knows how to
process version based archetypes you will have a framework that can
change to meet new storage media and presentation demands and all those
other technology changes we cannot yet see.  However, the data can
remain in the context in which it was originally recorded and be perable
within the framework.  

There are other reasons that are particularly sensitive when using SQL
databases. But, that is a long discussion and my time here is short. :-)

I hope this provokes more discussion on this matter because outside of
the people on these mailing lists there are few that agree at all with
this approach and a small percentage of those in health informatics have
even heard of it.  It is important to me that I can present a reasoned
case when I am in a situation that calls for me to discuss openEHR and
the two-level modeling approach. A reasoned case almost always calls for
practical applications where no other reasonable solution exists.

Cheers,
Tim


On Fri, 2005-10-28 at 13:23 +0100, Thomas Beale wrote:
> 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-invar

Archetypes and two-level modeling was: Templates - should we record which are used?

[Sandrine VILLAEYS]

Je suis en cong?s jusqu'au mercredi 2 novembre inclus.

I'm in vacation until the 2nd of November, 2005 included.

Sandrine Villaeys

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org