Syntax and Semantics

<http://www.idealliance.org/papers/xml2001papers/slides/De%20Grauw/05-

04-01.ppt>

Thanks for this. My favourite quote from it:

  1 The naive approach [to interoperability]

     Make a new vocabulary
     Make it real real real good!
     Make everybody use it!!!

[The author then gives examples involving delivery v. billing addresses
in invoicing sytems: not perhaps the toughest problem to solve?]

Archetypes from different ontologies can map to each other, perhaps, and
others evolve and come into the argument(s) as they are used. Do archetypes
and templates need to be registered? Not if meaning is use (as long as the
format is shared)

Any comment?

Whew! This is the problem. You need to be some kind of linguistic
philosopher to even join in the debate; but the reason why I am here
thinking about this is because I am a GP dissatisfied with the tools that
I use daily to record my activities, not through aptitude for Wittgenstein.

The only thing that I think I am sure about at this time is that the only
computer system it will be bearable to use in the age of computer
networks is one in which the components are freely shared and modifiable.
Will the components need to be registered? Well, I heard it said there is
no such thing as a private language; so I suppose so. It depends what you
mean by registered. How do we decide if a meaning is shared? How do we
prevent unwanted meanings from attaching themselves to our "pure"
technological language and muddying the water? How do we establish
author-ity? (and challenge authority?). The thing about natural language
is that it has some give, by virtue of the fact that two individuals can
use the same words to mean different things. Computer systems are not so
forgiving.

I think we will need social structures that allow every individual the
right of direct participation in this process of creating meaning or we
will create something either a) unworkable b) unbearable (or both?). My
experience of the practical reality of using computer coding systems is
quite often I cannot find an approved concept (code) to express myself as
I document a consultation; I could create a private code to do so, but
then there is no social structure to feed this back. Or I can use free
text, but lose the benefits of automation and searching.

This is a real problem: the fuzzier and more uncertain the knowledge that
we want to document, the more likely it is that a computer system that
forces us to document things in a certain way will force us to tell half-
truths. We can use certain euphemisms for this purpose e.g. viral
illness, that can then be recognised by a colleague as an expression of
something less precise than the literal interpretation might suggest; but
we're robbed if we think that this constitutes adequate expressive power.

D.

Doug

I agree with your sentiments. I have come to the belief that there are three
levels of knowledge representation within one clinical recording. The
highest level of standardisation is the pure clinical information concept
that we want to share - the primary archetypes. These are things like
diagnoses/problems or biochemistry result in the EHR world and not the
concepts that you will find in a terminology. This level provides semantic
interoperability - computers can find the information unambiguously. These
must cover the important concepts that we require for decision support and
other third party tools - reporting etc and in my opinion should be linked
to the same ontology that has given rise to the terminology.

The second level is are the shared organisational concepts - physical
examination, biochemistry report, history, assessmemt - providing what I
like to call 'clinical interoperability'. Physicians and other clinicians
often want to find chunks of information and read it - a whole report rather
than an individual level - the abdominal exam last time the patient was seen
etc. These must be shared and links to ontologies are helpful if they enable
more sophisticated querying - they are not required for semantic
interoperability and there can be many overlapping and shared organisational
archetypes. They do need to be registered at least in their base form (ie
non specialised).

The third level is that of the document (or part of a document) - setting
the sort of organisational models and what primary archetypes should be
stored in these (if that is what you want to achieve). In openEHR we call
these templates and they will vary hugely wherever they are used - they do
not need to be registered - but it might aid clinicians if they share these
to some extent. THey are based on best practice and local requirements.

More comments in line...

> Archetypes from different ontologies can map to each other, perhaps, and
>others evolve and come into the argument(s) as they are used. Do
archetypes
>and templates need to be registered? Not if meaning is use (as
long as the
>format is shared)
>
>Any comment?

Whew! This is the problem. You need to be some kind of linguistic
philosopher to even join in the debate; but the reason why I am here
thinking about this is because I am a GP dissatisfied with the tools that
I use daily to record my activities, not through aptitude for
Wittgenstein.

The only thing that I think I am sure about at this time is that the only
computer system it will be bearable to use in the age of computer
networks is one in which the components are freely shared and modifiable.
Will the components need to be registered? Well, I heard it said there is
no such thing as a private language; so I suppose so. It depends what you
mean by registered. How do we decide if a meaning is shared? How do we
prevent unwanted meanings from attaching themselves to our "pure"
technological language and muddying the water? How do we establish
author-ity? (and challenge authority?). The thing about natural language
is that it has some give, by virtue of the fact that two individuals can
use the same words to mean different things. Computer systems are not so
forgiving.

These are good sentiments and I think we need to grapple with much of this
as we go along - I think that when flexibility is required is has to be
there - that is HAS to be there!

I think we will need social structures that allow every individual the
right of direct participation in this process of creating meaning or we
will create something either a) unworkable b) unbearable (or both?). My
experience of the practical reality of using computer coding systems is
quite often I cannot find an approved concept (code) to express myself as
I document a consultation; I could create a private code to do so, but
then there is no social structure to feed this back. Or I can use free
text, but lose the benefits of automation and searching.

Participation is the key - not everyone creating meaning on their own.
Expressing what you want is not creating meaning in my books.

This is a real problem: the fuzzier and more uncertain the knowledge that
we want to document, the more likely it is that a computer system that
forces us to document things in a certain way will force us to tell half-
truths. We can use certain euphemisms for this purpose e.g. viral
illness, that can then be recognised by a colleague as an expression of
something less precise than the literal interpretation might suggest; but
we're robbed if we think that this constitutes adequate expressive power.

Again - we need to be clear about the purpose of collecting the
information - if it requires a very specific set of terms to be used - then
lets use them and in the same archetype lets have a place holder for the
full expression of the what we needed to say as a clinician. DV_TEXT (as an
abstract class) allows us to do this with mappings.

Cheers, Sam

I agree with your sentiments. I have come to the belief that there are three
levels of knowledge representation

<snip>

That all sounds very sensible, but a couple of points. There will always
be problems with the definitions at the boundaries. Even if the OpenEHR
defines things in the best possible way, there will still be clinicians
who fall short in their ability to correctly define things. They may even
blame the system for their own failings (it has been known... :wink: )

I think the answer to this problem is not to define ever better
definitions or archetypes or what-have-yous, but to take a leaf out of
the debian book, have public bug/issue-tracker databases on-line, and a
low threshold for acceptance thereto of comments, that may, in the
software engineer's eyes, actually reflect "training issues" (=user
shortcomings in computerspeak). But then, systemically, be ever so humble
in recognising that software must serve, and language must follow meaning.

Active email discussion among users, and a feeling that their
contribution will result in real change over time will help to keep the
meanings implied within the system close the the meanings the
professionals wish to impart to the system as they use it.

Although these seem like implementation points for a specific system, and
you doubtless have much grander aspirations than merely to implement
single system, I think the lesson of the whole free/open source thing is
that a freely available reference implementation is very valuable,
attracts users, and the resultant feedback makes the software stronger.

The only thing that I think I am sure about at this time is that the only
computer system it will be bearable to use in the age of computer
networks is one in which the components are freely shared and modifiable.

<snip>

These are good sentiments and I think we need to grapple with much of this
as we go along - I think that when flexibility is required is has to be
there - that is HAS to be there!

I think a good attitude on the part of the developers is probably the
most crucial aspect; I wouldn't be participating in this discussion if I
didn't trust you to do the right thing...

Participation is the key - not everyone creating meaning on their own.
Expressing what you want is not creating meaning in my books.

Quite. One of the whole purposes of training is to allow the initiate to
take a whole heap of stuff "as read"; and the purpose of the academic
community is to make sure we continue to have sensible stuff to read. But
the mores of that community: of debate, freedom of expression, and so on,
are probably worth trying to replicate in any software system worth its salt.

Again - we need to be clear about the purpose of collecting the
information

Yes... but what about the information we didn't know we wanted in the
future... ? For example, it's going to be an arid world for the medical
historians if they cannot capture the richness conveyed in the clinic
letters from the 40s - 70s that I can read to this day in NHS records.

Not everything that needs to be expressed, thought about, and studied can
be defined prospectively. We're too reductive in medicine as it is,
without making it worse with inflexible software...

D.

Douglas Carnall wrote:

I think the answer to this problem is not to define ever better
definitions or archetypes or what-have-yous, but to take a leaf out of
the debian book, have public bug/issue-tracker databases on-line, and a
low threshold for acceptance thereto of comments, that may, in the
software engineer's eyes, actually reflect "training issues" (=user
shortcomings in computerspeak). But then, systemically, be ever so humble
in recognising that software must serve, and language must follow meaning.

I think I have a pretty good understanding of this problem, from a clinicians point of view. The knowledge society to which I belong when I work as a rheumatologist has its own, constantly evolving language.

The ontology which in theory can be made from this domain must serve the purpose of the domain, and hence must be able to evolve. I believe its possible to build an ontology and an ontology maintenance infrastructure that both

* assists the expert language user (the clinician) when he chooses his terms and

* catches emerging concepts and terms and subsequently integrates them in the ontology

regards

Arild FAxvaag