In article <[log in to unmask]>,
[log in to unmask] writes a lot! Two points I want to comment
on...
>Lab results etc are likely to be local flows, they don't need a national
>system.
I disagree, they need much of the implementation to be defined and
developed Nationally, such as the message environment, the addressing
arrangements, the communications mechanisms etc. This is because we
want the results to be entered into our GP systems, in a standard
format, and we want our National GP system suppliers to support that.
They can't do that if every Trust/GP combination does whatever works for
them.
I do have reservations about NHSnet, but as many Trusts and HAs do need
to communicate with each other, and do need some national structure to
work within, it seems logical to use the same mechanism for
communication with General Practice, unless there are compelling
arguments against. This already happens with RACAL Health Link, and
despite problems, works in every HA in the country, and in some HAs over
80% of GP practices. That network uses Kermit protocols, which seem to
be limited for future development of communication, and I understand
when I asked for an extra RACAL mailbox last week that RACAL are
planning free upgrades to X400(88) for practices in the not too distant
future.
>Frankly I am not convinced that we need a communication service on a
>national level. I suspect that with only a couple of hundred practices in
>this area, a simple arrangement giving each of us a couple of time slots to
>dial up to a modem in the HA would work satisfactorily, and without the
>problems of Racal.
And you will also arrange with each Trust that you use to dial up to
them, - will you do it every day, or only when you have mail for them?
If the latter, what do they do when they have mail for you?
>The implementation of EDIFACT messaging in GP item of Service Links is
>incompetent. I don't know whether it was political incompetence, economic
>incompetence, systems analysis incompetence, programming incompetence but I
>have been convinced that it isn't operator incompetence.
Whoooaaa! I am no fan of the way the Registration and IOS messages were
specified but the problems you describe have nothing to do with EDIFACT,
but the functionality of the Health Authority computer.
>Do a night visit to a temporary resident.
>Record on the PRactice computer the morning after
> 1. Registration as TR
> 2. Night Visit to this patient. (can't do it in the wrong order)
The reason that you can't do this in any other order is that your GP
system is "patient based" not "admin" based. You can't record
"Clinical" things without having a patient recorded to attach them to!
Long may GP systems be "patient centered" - How long before hospital
systems catch up?
>2 transactions are generated. The last field of the Edifact message is the
>registration date, this includes the NV transaction. (note this carefully)
Absolutely. In other words, the EDIFACT message now carries all the
information needed to authorise your payment for Temp Res and Night
Visit. What the HA software now does is, I agree, ridiculous.
Interestingly, it is only the Admin stuff that requires such heavy
acknowledgements etc. The Clinical messages rely on non-delivery
messages, which seem quite adequate! If we had IOS/Reg links
requirements re-written to specify only the information flows needed,
then the EDIFACT message could be reduced for transmissions, and even
abolished for basic acknowledgements.
>uTrning now to travel immunisations, contraceptive service claims one finds
>the same sort of stupidity, when experienced FHSA staff who can see that
>the claim is valid cannot correct it so it is accepted and have to send
>back helpful notes like "delete India and substitute AS1"
The latter is a local arrangement by your HA, as we have previously
pointed out. The rules on FP1001 are arcane.
>Time to attend to what is transmitted, and what is done with it when it
>gets there, not to how it is carried I think.
I agree, but blame the implementation not the EDIFACT message.
--
Jon Rogers
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|