In article <[log in to unmask]>, Adrian
Midgley <[log in to unmask]> writes
>I think that the answer is as referred to in the message quoted from
>above, bound up with IMG's efforts to get a grip on us by the wires.
>
>This was rightly interpreted by most of the cynical and interested
>target poulation as being obfusc and irrelevant to our interests -
>empire building rather than service.

Yes - now that I CAN understand.  And I would hope and expect that
people on this list will keep on voicing their views about 'the wires'.
We need to get NHS E to understand that they have to take a very long
hard look at 'the wires'.

The important thing is not to dump everything in sight just because it
is organisationally associated with NHSnet

>
>The GPPL offers much, but any temptation to discuss things in quiet
>asides, and then present transport mechanisms and other bits of
>technology as an inseparable part of the main aim will lead to a
>resurgence of inflammatory scepticism among onlookers.

I hope we have reached the stage where these things will all become very
open - watch this space
>
>The simplest answer about EDIFACT versus HTML is that I can write HTML
>using Windows Notepad, whereas EDIFACT is effectively proprietary, and
>resistant to innovation.  Even if none of us _ever_ innovated, unlikely
>given the degrees of technophilia and hubris exhibited daily on this
>list, we all feel safer and happier if we think we could.

>Mind you, I reckon that if one turns out a plain text file with a few
>tilde separated values in it and some full figure times attached, and
>splits a few records into two lines GOK why, the result should run
>through an EDIFACT translator like nobodies business.  Analysis by
>experiment anybody?

Adrian - good point.  I have not ever sat down to produce the necessary
plain text file with delimiters that would define a syntactically
correct EDIFACT message.  However, I suspect that it would not be that
difficult though of course we would not have editors such as exist in
the Public Domain for creating HTML documents.

The real issue is NOT the difficulty in writing the code that will pass
through an EDIFACT translator.  It is the major difficulty of getting
everyone to agree what should be included, and how each piece of
information should be represented.  This involves many people in many
hours of work - primary care and secondary care clinicians, and
informaticians who have experience of sorting the sheep from the goats.

For some reason many of the proponents of HTML assume that their piece
of technology will make it completely unnecessary to do this important
preparatory work with the human beings at each end.  Some of them even
talk of the 'document paradigm' v. the 'messaging paradigm' which is
really most bizarre.

Yet an EDIFACT message is actually an electronic analogue to a paper
form.  It holds the information in a predetermined and predictable
structure - i.e. provides the slots into which data can be put (and
includes some validation).  I am not an SGML expert but understand the
tagging that for example we all use in our HTML documents.  The tags can
define 'slots' into which information can be put - so again the document
has some structure.  HTML can therefore act as another analogue to the
paper form.

HTML clearly wins hands down on displaying data as EDIFACT is not
designed to aid display.  But content wise an HTML document tends to
amount to an immense amount of bytes for very little information.  That
makes electronic searching a bit slow.

But there are problems that are being glossed over time and time again.

Who will:
        a)      define all of the tags that we need so that we can all
be certain that they are what they seem to be
        b)      decide which information items we want in all of the
various situations where we want to share information
        c)      ensure that when an HTML document visibly 'says' that
something is a 'diagnosis' that the information really does have the
correct (invisible) tags

        I suspect that some may answer that they know what something
means because they can read it off the page.  True enough - but we are
not simply talking about display of data (which of course HTML can do
brilliantly).  Unless you actually check the tags for each item how will
you know that every 'slot' has been tagged appropriately for what you
see?

Apart from display we will also want to store at least some of this
information locally (or possibly centrally) so that we can use it to
underpin decision support / audit etc etc.  If we are going to do that
then it will need to be stored in a way that allows fast, reliable,
unambiguous data retrieval.  HTML documents do not support that as yet,
and I haven't seen any discussion on this list of how the 'document
paradigm' will communicate with the 'database paradigm'.  EDIFACT is of
course designed precisely to exchange data from one database to another.

The debate that I recognise is the comparison of document based v
database solutions - and that is a sensible debate worth having.  I hope
that in future we will use the best of both in the most appropriate way.

Rather than you or I waste time proving we can write the text file to
'fool' an EDIFACT translator - which I am sure we would succeed in doing
sooner or later - a more interesting proposition would be to try and
feed an HTML document with an EDIFACT message and perhaps vice verse.

I have a feeling that this should be to some extent possible.  It might
even be useful and I would expect we would learn quite a lot in the
process.  EDIFACT just might provide one possible bridge between
databases and documents.
--
John Williams
Email: [log in to unmask]
Fax:   01483 440928


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