On Monday 16 June 2003 23:56, [EMAIL PROTECTED] wrote:

> While I am not a technical guru, I do have a very busy
> private practice in Family Medicine that is not funded by
> anyone except myself and what I can generate out of the
> practice.  

Me also.


> I recently was forced to switch a working program to
> another vendor 

The loss of service from a proprietary system and company due to 
commercial events  was what convinced m that Open Source is a 
necessary but not of itself sufficient condition for 
satisfactory IT service to family practices, and by extension to 
tertiary services and patients.

I termed it "Ars Longa, IT Brevis" and occasionally mention it. 

This in my view is a sufficient argument in itself for changing 
from proprietary systems; resisting or delaying the 
introdduction of proprietary systems in un-automated 
establishments; accepting rudimentary FLOSS systems which only 
address half the the requirements of a specification.

In producing systems that are intended to persist it is 
desirable that a theoretical description and understanding 
exists, and over a long time-scale and in areas such as the  
movement of patients and components of their records from one 
system to another this should eventually produce a large payback 
(tending toward the difference between n**2 and 2n in a world of 
n systems or at least the cost of retyping every item in every 
incoming medical record and the value of lost or altered data in 
that process)

At the same time, medicine is an intensely pragmatic discipline 
and business, and the great bulk of work can be handled as 
individual jobs.  Software that handles a common process - call 
for immunisation, record immunisation, claim payment for 
immunisation, throw off statistics about immunisation, handle 
the knowledge service for immunisation - can be very useful.  
The tech challenge is to write such a piece of process 
automation without backing everyone else into a corner of having 
to use the same perhaps incomplete theoretical model to the 
detriment of eg the handling of decision support on ordering (or 
as we say "requesting") a computer tomogram of a head...


> What I would appreciate from this list 

Is not actually the charter of this list.
You asked for ways to cope better with the present situation of 
ownership and inaccessibility of automation, whereas we are 
committed to replacing that with a situation where you might 
well diffuse your 3 year search into a constant need to sponsor 
awareness of developments, but there would be no sudden 
discontinuities, and in the last analysis when your supplier 
went feet-up you could not be prevented from paying for 
modifications next time your government required them.




-- 
From the Linux sofa or garden swing of Dr Adrian Midgley 
http://www.defoam.net/             

Reply via email to