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.