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

You are missing the point.  I am beginning to wonder if people are
deliberately missing the point!  I believe not.

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

Granted.  No probs with that.

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

It is somewhat inane to view the Web as messaging, but I'll let
that go.  On the subject of "the answer", the fact is that it is the
IM&T strategy that is ramming messaging down the throats of the NHS as
"the answer".  Our argument is to make everyone see sense in the face
of such policy.


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

Hey - why not get Read Codes in the discussion while we are at it.
I'm sorry but this stuff is bordering on the "let's see how difficult
we can make things and not get anything done till we have worried the
issues to death".  Oh and let's spend a load of money and time doing
it in an EC funded project.

I'm sorry but if you are interactively accessing, say, a path system,
viewing the results for Mrs Bloggs that the pathologist has prepared,
have you,  as a  GP got a problem with understanding the info on the path
screen?  'Coz if you do,  then you also have a problem looking at the
same info that currently arrives at your desk by post!!


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

You've missed the point again.  In our context, HTML is simply the
language that drives the presentation of info on the screen, in the
same way as escape sequences and control codes drive a VT100 dumb
terminal display.

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

Or we could just get on with it.  But that's hard (I am being
sarcastic as well as ugly!)  God! Why do I feel like I am in the
States and having to explain jokes??

In any case, 3 and 4 are the wrong way round - if you decided in 4
that the Web was the way to do it, a messaging based infrastructure
put in at 3 would be a bit of waste of time. I am getting a bit of
deja vu myself.

> I suspect that much WWW technology will be found in many non-web
> systems very soon, and I welcome this.

Don't get that.  What do you mean??

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

The back end system (eg the path system) can track all that activity,
and replay it back to the GP on request (via the web browser access if
needed or on paper as an audit trail).  Why does that activity record
have to (again!) be held by the GP on his precious GP system?

This is all down to policies and good practices and confidence. Again
do we not do anything till every issue is worn down?  Do these cows
ever come home?  Haven't they been home and milked for ages??

Risk
alright,  you can chuck me out now....

---------------------------------------------
Dr Ahmad Risk
The Medical NetNoire


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