(Apologies to Ahmad - I didn't check the header!)

This discussion has generated a very strong feeling of deja vu...it once
again treads the old ground of "this (my?) technology is best!".
Alternatives are vociferously endorsed, but the question "best for *what*"
hardly gets a look in.  Solutions looking for problems yet again.

One of the underlying problems is surely effective communication to support
a range of (decision making) tasks, as well as keeping a record of both
communication transactions (patient-clinician, clinician-clinician,
machine-machine, etc.).

Both messaging and client-server paradigms (and the WWW is a mix of the
two) offer powerful facilities, often complementary but not yet fully
harnessed (at least, not in the clinical world).  But neither is "the
answer".

Jon Rogers is absolutely right to emphasise the need for structure,
although this may be considered a proxy for setting out a framework of
understanding or context (the word "diabetes" doesn't mean anything unless
you add something like "the patient does not have...". Similarly, "1mg/l"
has to be tied to something to make it meaningful).  Doing this is even for
simple things like lab results is hard.  Doing it in a general way for more
complex communication is very hard indeed, so people avoid it. You have to
understand how the same term can convey different meanings which are then
used in the context of a particular decision.  For most medical tasks this
analysis is not yet available, nor are the semantic models (sorry about the
jargon) to underpin unambiguous communication.

Both EDIFACT and any html-baed system are structured.  They have to be to
permit interprtation (html is a language with a formal semantics, based on
SGML, so anything written in it will derive from and be framed by that
structure).

So, a rational plan could be -

1 - decide what tasks need to be supported
2 - define the information needed
3 - build the infrastructure to allow unambiguous communication of that
information
4 - decide which mechanism is the most appropriate for achieving this

I'm interested in seeing more about the first two of these, leading to the
third.  4 has plenty of candidates.

I suspect that much WWW technology will be found in many non-web systems
very soon, and I welcome this.  But, as always, there are drawbacks, some
specific the client-server model.  Copying a mesage locally may violate a
data-integrity principle, but it can provide a record of what was received
and acted upon - what is the legal position if the central server is
capable of being changed or messages corrupted?  There are many other
issues to consider.

Andrzej Glowinski




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%