>Interesting argument, but you seem to feel that HTML is somehow
>structured to allow the sharing of say path results.  It is not.  To
>transfer data into another application, eg a GP recipient system, the
>data must be structured so that the possible elements within the message
>can be carried unambiguously.

And here is where the fundamental issue lies - the current
wisdom/paradigm that says it is essential to move a copy of the data
from their system to yours.  The Web paradigm allows you to break from
that thinking.  Every time you need (or think you need) access to that
path record, your browser gets it (or attempts to get it) from the
source location - the pathology system where the result was recorded.

Why do you currently think you need a copy of the result in your GP
system? - because that's the way the systems have been developed in
the past and the then practical constraints on sharing of information
dictated.  That's gone now with the Web.  The data, therefore, can be
structured as the source information dictates (ie on the legacy path
system).  The results can be delivered to you laid out as a web page
of your choosing if necessary - to nationally agreed protocols if
absolutely necessary (personally I think that is impractical,
uneccessary and will take for ever, but others may think otherwise).

You need to separate content (ideal standardised data structures v how
legacy systems hold the data) from transport (http v X.400) and
presentation (GP system's built in display of path results it receives
v HTML/Web browser display of results received from source).

Sadly, EDIFACT bundles content and transport together and muddles much
of the thinking.  The whole messaging paradigm is based on overcoming
last year's infrastructure and system limitations.  Web tecnologies
blow it all (or most of it) away.

>
>If you look at a line of text:
>
>John Smith 1.3.82 Hb 13.2 WCC 5.4
>
>you could probably deduce that John Smith has a date of birth 1.3.82 and
>has an Hb and Whitecell count as specified.  For a computer to reliably
>understand it one needs to spell out which bit is surname, forename,
>date of birth etc.
>

That's a presentation issue. Interactive web based access to the
source path system would make that context clear - the basic stuff of
applications.

Your argument is only right if messaging is your paradigm.

>>3. My question is:  *why* do you need to send structured messages in 
>>the first place?  To date,  no one has come up with a convincing 
>>answer.
>
>See above.  I can't see how publishing lab results on the NHSNet in HTML
>format, without a structure, and it is reliably interpreting that
>structure which is the hard part of EDI.

Don't think "publishing".  Think interactive remote access to the
source path (or whatever) system.  The Web provides the infrastructure
and technology to make this practical, cost effective and
straightforward to do. 

>
>>a) Trust A 'publishes' the path results as they are onto the intranet, 
>>ie,  in which ever format the existing system produces them,  only in 
>>HTML format (no need here for edifact at all) :-)
>
>1-2-82, Smith John, 7.12.96, Haemoglobin 13.2 g/dl, etc?  How will you
>show an MSU, U&E results etc...
>

A presentation/source application issue.  

>>
>>b) GP B dials up (securely and all that) and logs on to his 'authorised' 
>>area of access and views or downloads his results.
>
>OK, but all he can do is download and view them?  He/she can't populate
>his clinical system
>

So what?  Why do you stick to the belief that this is important?  If
you had the means of getting the results from source every time you
need to see them, then you don't need a copy on your GP system, do
you?

So, OK, this is predicated on having high bandwidth comms at
reasonable cost, and requires amendments to existing systems.  But
wasn't the former a key aim of the NHS network (and ask your local
cable company what they could do for you!), and aren't mega changes
being required at mega cost for existing systems anyway to implement
messaging (and taking a mega long time to happen)?

Also - let's look at a key benefit of Web v messaging.  If I'm the
pathologist and I send you the results to stick in your system, I've
lost control of the information.  Hence we get into all the talk of
digital signatures, etc etc.  Basically once you have the copy,
though, you can/could do what you like with it.

If, on the other hand, you had to come to the path system every time
you want the result, then I, the pathologist, retain control of the
data via an access control list that I maintain - the stuff of
application systems.  (Thinks - sounds like one of the BMA
principles...sounds easy to implement.....)

>>I know that I may be shot down by the edifact/X.400 lobby.  My only 
>>hope is that the mind may be set free to consider the alternatives.
>>
>
>I am happy to consider alternatives, but I think these are not yet
>complete, but keep them coming!

What is it that's not complete?  It's demonstrable today (contact me
and I'll show you).  It's readily implementable. If something needs
further work, let's get on with it and do the investigative work.

>
>>I also know that you might say " ah,  but we need to integrate those
>>results with our medical systems databases".  The problem here is
>>the GP computer systems and the strategy not the solution offered.
>
>I think you are wrong on what the problem is, as stated above.

Rather depends on your point of view.....

>
>>All I am asking for is that people begin to say we have made a
>>mistake.  It is good to say that.  When the strategy was conceived, 
>
>There is a future for both HTML and EDI - horses for courses!

IMHO, close investigation will show that EDI is really only
appropriate to a small proportion of healthcare information needs.
Let that close examination begin !



---
Rob Tweed
IM&T Consulting Ltd; Health Web Services Ltd;
M/Gateway Developments Ltd

http://www.hwsl.co.uk/mgw
Tel: (+44) 181 540 1325
Fax: (+44) 181 715 4337
---


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