On 20/05/2006, at 8:29 AM, john dooley wrote:
Horst, the big firms dont think in tbird/pgp/python script terms
and you
very well know that. They think in MS/ java / vbasic terms.
Well if they want to make things hard for themselves who do they have
to blame!
How much time
do you reckon it cost Symbion to set up their end for you to have the
python solution so their mainframe is okay with it? half a programmer
day? a day? for one outspoken GP...
A PGP encrypted email? 5, maybe 10 minutes.
How many different solutions have to be implemented like that to keep
everyone happy?
One sensible one.
How about you GP IT guys get together and write or at least
participate
in getting GPland a universal download client so that everyone can
send
results you
Good idea. I think that's sort of what Horst did, except that he
stopped at the point where it was working for his needs, but at least
one other is now benefiting from the same system.
and promise not to phone if you cannot get results when its
installed on the pc in the tea room, and take ownership of the
issue a bit?
That way you would solve your IT support problems yourselves?
Now you're generalising. The majority of our sites tend to know who
to phone - the path company if they are missing one result but have
others, IT support if they are not getting anything. We now have some
path companies watching their logs and contacting us directly - lucky
we don't bill for the small stuff because I don't think they'd
appreciate an invoice!
I love the way path services are deemed generic enough that you can
"force" them to install their software for you your way and provide
support on your terms or you'll take your bat and ball and go
elsewhere
to someome who does it your way.
Hang on - install their software on whose computer? The owner of the
system or the one responsible for it should dictate the terms to
every third party that wants to install anything! Drug reps who
throw CDs into the server are never to be seen again!
I guess thats the harsh reality of
life. But mind you I dont see referrals to specific surgeons being
treated the same when they dont send electronic letters and have to
have
paper scannned :P ...
Correct me if I'm wrong, but the difference between surgeons is
probably a lot more important to the outcome than the difference
between path companies, and there is a lot more volume in the path
market, making efficient delivery more of an issue to the GP.
Is there really significant issues with "server crashes" (meaning
nonfuntioning servers) as a result of misbehaving download apps or is
this more FUD being spread... hands up who has a solid example of
a DL
client killing a server.
Java doing a memory leak and overloading a server so it's not
responding - seen more than once. Java installations overwriting each
other and stopping other software working, rare now but saw several
early on. Installers that don't have a clue how to install on a
terminal server and end up starting a process per user - still very
common.
I dont mean costing 10% more CPU cycles in
perfmon(who cares)
I do. 10% CPU cycles, or more likely, RAM usage that should be
devoted to a database server, the most popular of which will use
almost all the RAM in the box = 10% slower everything. 10% slower on
a workstation is livable with, on the server it's not on. In a client/
server environment I like my database servers to run almost nothing
but the database and an efficient AV client (I also run this server
on a workstation). They tend to run very quickly and be very reliable
compared to the SBS kitchen sink approach.
Come on guys, remember that the path companies for lots and lots of
reasons want a robust d/l system too and work with not against them to
achieve that. Drop the us and them attitude....
No argument there. I simply request that we are allowed to install on
a workstation for very good reasons that outweigh the benefits of a
server install. File permissions are dead easy and never require $ to
fix, in the very rare case that they break after installation.
Our recipe is to install on two workstations, turning one copy off,
so if there is ever a problem with the workstation there need be no
path downtime. When one of those workstations is replaced the path is
dealt with in a non emergency situation, rather than in the early
hours of the morning with dead server bits strewn all over the floor,
you've been at it since daylight and have everything just about
perfect, then realise there's only the path and radiology to go - how
many proprietary clients this time?
I don't think asking for improvement and cooperation and standards is
unreasonable. You didn't re-invent the wheel John but most larger
pathology / radiology companies did and seem to have too much ego at
stake to even consider an open, standard client.
Peter.
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
