At 19:25 +0000 on 28-12-1996, John Williams wrote:
> In article <v03007805aede20dcf389@[194.151.26.66]>, Gerard Freriks
> <[log in to unmask]> writes
> >> The earlier discussion was generating some light, alas replaced by heat.
> >> At the risk of picking the scab, from a user requirement perpsective I
> >> wondered whether both sides were right.
>
> As Senior User to the GP Provider links project I find the title to this
> thread most extraordinary - a bit like saying 'commuters v trains'.
> Commuters can use a wide range of transport mechanisms such as cars,
> buses or trains.
>
> EDIFACT is in some senses the electronic analogue to a paper form.
> Paper forms can be placed in envelopes and then posted. EDIFACT forms
> can be placed in envelopes (e.g. X400 or MIME / SMTP) and then posted
> across a network which can be Local or Wide. The WAN can be 'closed' or
> 'open'. Thus one of the options for EDIFACT 'forms' would in theory be
> to place them - suitably signed and sealed - on to the Internet.
>
> The GPPL project is actually developing just such a 'signing and
> sealing' solution which would make it possible to send clinical EDIFACT
> messages securely across any WAN or LAN - whether NHSnet or Internet.
> The GPPL approach does NOT depend on X400.
>
> It is important to separate out the GPPL project's approach to clinical
> EDI and IMG's policy. It is IMG / Syntegra policy that X400 and NHSnet
> should be used. In reality, at least in the short term, in practical
> terms it may prove to be impossible for GPPL to use either.
>
> EDI should not be bracketed with email. It may be possible to go quite
> a long way with standardised email layouts but if you really want
> reliable computer to computer exchange of information the work involved
> in getting the layouts agreed and then policing them to ensure everyone
> complies makes EDI a much better longer term solution.
>
> The failure so far to deliver EDIFACT frankly has much to do with IMG's
> obsession with 'the wires' and failure to recognise the need for co-
> operation between clinicians, suppliers and the Data Interchange
> Standards people. In the last 12 months the GPPL project has succeeded
> in getting all of these people to work together with the result that all
> the major GP suppliers are now producing the missing clinical EDI
> management software. We are still struggling to get IMG to understand
> that this is at least as important (if not more so) as 'the wires'
>
> Meanwhile IMG / Syntegra are still struggling with the wires
>
> The clinical EDI we are talking about is very simple - initially
> enabling pathology and radiology results to be received, and matched to
> the individual patient. Discharge letters will also be received
> initially as text that can be linked to the patient's record. This is
> NOT claimed to be the 'be all and end all' of communications but just
> one small step on the way. The hurdles that the GPPL project has had to
> negotiate are not peculiar to EDIFACT. The most difficult ones have
> been mainly human and political. They exist for any project trying to
> implement something new - and SGML / HTML would be no exception.
>
> I am not sure what EDIFACT has done to deserve this 'ugly duckling' type
> of treatment. If we can soon make it work safely and effectively and
> make it available at a resonable cost will people not want to use it?
> Meanwhile we should be pooling of knowledge and experience. It would
> take many months to get web based solutions in place even if the main
> proponents had a clear plan of action. There does not appear to be any
> clear plan as yet, so it will take even longer particularly as there
> appear to be problems to solve that have not yet been addressed .
>
> Meanwhile while keeping an open mind on new developments, we can make
> progress with EDI, benefitting patients, encouraging the development of
> secondary care clinical systems, and learning many valuable lessons in
> the process
> --
To be frank.
Nothing is wrong with EDIFACT. It works, there are standards!
And the general free text standard for EDIFACT is a perfect wrapper for
SGML enhanced messages. No ugly duck thing at all!
But..
Did you ever thought how difficult it was to get at an EDIFACT standard?
How difficult it is to change it?
How many dialects there will be? (In Holland there are to many. One area
cannot exchange information with the next one, because they use a slightly
different one. In general we are very disapointed about the general
usefullness of EDIFACT in medicine. It will work perfectly in small very
restricted communities for very restricted purposes, but not generaly)
How unforgiving EDIFACT is?
How rigid EDIFACT is?
And then..
Even if we will use the Document metaphor (and SGML) then we have to decide
about a lot of other things. Think of ..
How many ways are there to write names, adresses, dates, etc, etc
(But using EDIFACT you will have the same problems)
SO..
Please continue your work.
And connect database A with database B, using system provider X and provider Y.
And rapport about the longterm results.
And eventualy your way and (any) alternative can be compaired.
Thats research, that is science.
No problems at all.
Bye the way SGML is a technical way to implement the Document Metaphore as
opposed to the Database Metaphore.
EDIFACT is a very decent envelope, but no good way of general flexible
marking up of documents so that the context is stored with the data.
Greetings
Gerard Freriks,huisarts, MD
C. Sterrenburgstr 54
3151JG Hoek van Holland
the Netherlands Telephone: (+31) (0)174-384296/ Fax: -386249
Mobile : (+31) (0)6-54792800
ARS LONGA, VITA BREVIS
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|