> Nothing is wrong with EDIFACT. It works, there are standards!

It works badly because the standards are wrong. They are wrong
because they are cobbled together by small groups with their own
agendas, who do not seek the input of all interested parties and
reject this input if it is offered.

To consider just the safety aspects: the EDIFACT messages of which
I am aware have nowhere to put a digital signature. Back in 1995, I
agitated for such a field to be added before the messages were cast
in concrete. I was assured that this field would not be needed, or
that if it was then the signature could be added afterwards in an
external envelope. I repeatedly explained why this was a bad idea,
but was unable to get past the usual smug rationalisations (we've
done a lot of work on this; it would be too much trouble to change
it; I'm a doctor and you're not; how come messages for X are
security sensitive; I don't really understand what you're saying
anyway; we don't want to get this project entangled in the IMG/BMA
security dispute; we're happy that what we've done; go away).

I will forbear for the time being to name the guilty parties (at
least two of them are members of this list).

The reason that signing the envelope, rather than the message, is
a bad idea are as follows.

(1) For digital signatures generated by an individual clinical
    professional to have medico-legal force, she must see each
    message as she signs it. If the EDIFACT security software is not
    built into the end system but needs to sit between the network
    and the EDIFACT translator (which often serves a whole hospital
    LAN), then this legal force is much diminished. All the signature
    says is that somebody fed this report into the path lab LAN
    sometime that morning.

(2) So the report could have been corrupted between the pathologist
    and the EDIFACT gateway on the way out, and it could also have
    been corrupted between the EDIFACT gateway and the end user on
    the way in. Given that most accidental (and deliberate)
    corruption of data is local rather than network-based, what have
    you really achieved?

    This problem is well known in the world of electronic funds
    transfer where there are quite good message authentication
    systems used between participating banks, but which usually stop
    at the gateway. The result is that all the big accidents - and
    frauds - occur in local systems. Programmers put bogus funds
    transfer instructions into messages queues in the mainframe, and
    technicians tweak the LAN to cause bogus instructions to issue
    forth from local printers. Computers, as is well known, get fits
    and issue credits and debits to randomly chosen people. The
    situation is difficult to improve because the authentication
    mechnanisms are out of reach behind the EFT system gateway.

(3) Where the pricing is X per message plus Y per kilobyte, people
    will configure their EDIFACT systems to batch messages. So you
    get a signature on a batch rather than a message. The signature
    on a path report will be the electronic equivalent of `this is
    the 30/12/96 AM batch of reports from Dr Smith's laboratory to
    the Little Wallop practice'. If the EDIFACT security software
    sits behind a translator that is shared by all systems on the
    hospital LAN, then even the link with Dr Smith as the clinician
    responsible for the pathology lab is probably lost.

(4) Quite apart from the issues of safety and immediate legal
    accountability, you have a further problem with accountability in
    the future. The signature will not be able to be checked in
    five years' time unless all the messages in every batch are
    retained. That would not only be expensive but likely breach the
    Data Protection Act, as well as GMC ethical guidance and the BMA
    principles: you would end up not being able to demonstrate the
    signature on Mrs Jones' cytology report without also disclosing
    the reports on twenty other patients, some of whom would likely
    have died, gone away - or restricted access to a single physician
    following a positive HIV test, for example.

I am quite aware that John Williams' GPPL team are trying their level
best to engineer around these problems. But the problems should not
be there in the first place, and even if the initial implementations
manage to patch things up somehow, there will always be the terrible
temptation to `optimise' - whether by batching the transactions or
consolidating the processing. In either case much of the safety,
and most of the medico-legal assurance, given by digital signatures
will be lost.

The way to think of it is this - the new `electronic' lab report
forms have no space for the pathologist's signature. Instead the
signature is affixed to the envelope. You now rely for the rest of
eternity on procedural dicipline forcing everybody to only ever put
one form in each envelope, and keeping all the envlopes for ever
after just in case there is a dispute.

This is really dumb, and - as people have been pointing out - once
an EDIFACT standard gets accepted it gets coded into so many
different applications that it becomes impossible to change.

I would have vetoed these messages if I could, but there was no
mechanism available; EDIFACT messages are developed by small groups
in cahoots with IMG, which then pushes the standard through quickly
before anybody has time to argue. This is not the way to run things.

What we need is a mechanism for public review of all strategic
decisions that will be very hard to change later (such as the
definition of new EDIFACT messages). If interested parties find a
serious flaw, then there must be an effective power of veto.

This would mean an end to the current fashion of trying to push
through unpopular administrative changes stealthily, by tinkering
with computer systems. However, that would be no bad thing - and
perhaps a suitable New Year's resolution for our lords and masters?

Ross



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