The Law will always be an ass - the courts make decisions on a case by case
situation. This does not imply they should be ignored! The law will never
give a ruling till after the event!!
Pull back and ask what is good messaging??
It is a message which goes to its intended reader.... and better than this
....one dispatched and the sender is aware it has reached its reader.
The technology to do this is not hard or fastidiously complex!
The .ack file from clinical software to clinical software is a sound
starting point. Some might argue they want another message to indicate the
message was read by said doctor (eg like the 2 options in outlook
acknowledge message received THEN acknowledge read)
The current situation is drop the results in a holding pen and hope the
clinical software reads it. There is no surety in this. For those who claim
100% success in electronic path transmissions to make it to patient file
level ...... has anyone of your doctors ever phoned pathology for a result?
... WHY DID THEY PHONE? - was that a missing result? Was it reported - to
whom? Was it investigated? But by whom?
Unless systematically look closely you are unlikely to notice the odd
missing FBC or EUC maybe only 1 in 100 to 1:300 If you are a small
surgery this is may be a once a year event?
Acknowledgements issued by the transmission clients own sending receiving
systems are technically useful for trouble shooting IT problems but are
medical bunkum in terms of PATIENT SAFETY OR CLINICIAL SUETY.
FROM EARLIER POSTS ..it was argued that the results dumped on the server are
the same as "paper results" dumped by a "courier" at the front desk .. I
have sympathy for the analogy but it is deficient...
1) results on paper are in a ready to read (english??) format at the front
desk with a "minimal skill" set required (ie recognisable paper as pathology
results )Business protocol dictates how they are distributed internally.
CONTRAST .. HL-7 dumped on a server [outside of the clinical app] are not
available to a doctor at "minimal skill set". You need to know computing
skills well beyond the clinical app skill set to find them, discuss
correcting the problems etc etc However it is reasonable to expect the
doctor to be able to run and monitor issues WITHIN their clinical APP.
2). In our practice if something is important, such as chasing a slack
patient about their CIN 2 pap (assuming we cannot reach them by phone or
they fail to attend ) then return paid certified post is the next step ....
this scenario ensures Australia post - the carrier of paper- identified the
receiver and returns an ack to our surgery indicating the patient received
the important message OR When There is NO ACK and we find the message could
not be delivered and have to look to solve the ability to make contact !!
Hence I am not yet dissuaded from the minimal patient safety is clinical APP
to APP .ack systems WITH A BUSINESS PROTOCOL for reconciliation.
In this scenario if my patient asks why did I get cancer when pathology sent
the result which was not acted on ..... then like an aircraft crash I know
the event involved either catastrophic Computing scenarios (still the result
was lost after the .ack message ) OR human errors (assuming I have
maintained due care) ..... MOST IMPORTANTLY IF IT IS MY DAUGHTER I CAN WITH
A CLEAR CONSCIENCE {but sad heart!!) say I tried really hard to avoid this
happening!! IS this not the spirit of our profession and humanity?
Can someone mount a more convincing alternative view of messaging
responsibility?
Craig
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, 13 March 2007 1:00 PM
To: [email protected]
Subject: Gpcg_talk Digest, Vol 18, Issue 35
Send Gpcg_talk mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gpcg_talk digest..."
Today's Topics:
1. Re: Internet redundancy (Greg Twyford)
2. Re: Messaging Responsibilities (Greg Twyford)
----------------------------------------------------------------------
Message: 1
Date: Tue, 13 Mar 2007 09:45:21 +1100
From: Greg Twyford <[EMAIL PROTECTED]>
Subject: Re: [GPCG_TALK] Internet redundancy
To: [EMAIL PROTECTED], General Practice Computing Group Talk
<[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Andrew wrote:
> No not dreaming,
> Lost count of how many home networks we manage because they are connected
to
> the surgeries sometimes via a dial up vpn.
>
> Its better than not managing them.
>
> Andrew.C
>
> -----Original Message-----
> From: Horst Herb [mailto:[EMAIL PROTECTED]
> Sent: Monday, 12 March 2007 6:54 AM
> To: [EMAIL PROTECTED]; General Practice Computing Group Talk
> Subject: Re: [GPCG_TALK] Internet redundancy
>
> On Sunday 11 March 2007 22:39, Andrew wrote:
>> Really only works when the client agrees that we also manage their
>> soho network.
>
> Are you dreaming?
Yep,
I manage the home networks of my VPN users too, kids' PCs and all. The
doctors in question realise they need it.
Greg
--
Greg Twyford
Information Management & Technology Program Officer
Canterbury Division of General Practice
E-mail: [EMAIL PROTECTED]
Ph.: 02 9787 9033
Fax: 02 9787 9200
PRIVATE & CONFIDENTIAL
***********************************************************************
The information contained in this e-mail and their attached files,
including replies and forwarded copies, are confidential and intended
solely for the addressee(s) and may be legally privileged or prohibited
from disclosure and unauthorised use. If you are not the intended
recipient, any form of reproduction, dissemination, copying, disclosure,
modification, distribution and/or publication or any action taken or
omitted to be taken in reliance upon this message or its attachments is
prohibited.
All liability for viruses is excluded to the fullest extent permitted by
law.
***********************************************************************
------------------------------
Message: 2
Date: Tue, 13 Mar 2007 09:47:45 +1100
From: Greg Twyford <[EMAIL PROTECTED]>
Subject: Re: [GPCG_TALK] Messaging Responsibilities
To: General Practice Computing Group Talk <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Richard Hosking wrote:
> Interesting read.
> Still they appear to be basing their standard on a legal opinion. This
> seems to me to be the tail wagging the dog. To some extent this opinion
> will be based on contemporary medical practice, which will no doubt be
> influenced by what the RACGP sets as a standard!
> Shouldnt we be setting standards ourselves?
Sorry Richard,
law is overarching and precedes medicine and everything else, wheher we
like it or not.
Greg
--
Greg Twyford
Information Management & Technology Program Officer
Canterbury Division of General Practice
E-mail: [EMAIL PROTECTED]
Ph.: 02 9787 9033
Fax: 02 9787 9200
PRIVATE & CONFIDENTIAL
***********************************************************************
The information contained in this e-mail and their attached files,
including replies and forwarded copies, are confidential and intended
solely for the addressee(s) and may be legally privileged or prohibited
from disclosure and unauthorised use. If you are not the intended
recipient, any form of reproduction, dissemination, copying, disclosure,
modification, distribution and/or publication or any action taken or
omitted to be taken in reliance upon this message or its attachments is
prohibited.
All liability for viruses is excluded to the fullest extent permitted by
law.
***********************************************************************
------------------------------
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
End of Gpcg_talk Digest, Vol 18, Issue 35
*****************************************
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
