gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Results tracking


From: catmat
Subject: Re: [Gnumed-devel] Results tracking
Date: Sun, 06 Mar 2005 08:34:49 +1100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231

Karsten Hilbert wrote:


Do we actually lose anything by shifting to the structure Ian contemplated?
We lose doability since test_result and blobs are in
different gnumed services (and therefor likely databases).

at work , the secretary showed me a stack of paper to be scanned
in about 15 cm high each day. 50 x 5 x 15 = 25 metres a year.
I can see why one might want to a separate service for blobs.
Maybe there will be a need to build some sort of server farm to serve out a huge
document repository in the future.
The most popular EMR in oz, (you know who), recently grafted a
document management system in its next version, after being out for 4 years now.
Our single server chokes in throughput sometimes : not sure
if it's our lack of scsi drives, lack of cpu performance, lack of
gigabyte switch and network interface cards on all computers,
or using network file system locking to implement concurrency
for medical record access, or just the an excessively sized
not highly scalable database system used for our emr (we know it isn't the clients,
because they were upgraded and it made no difference to choking sessions).
It seems to choke when someone is scanning documents
Our manager forbids us from using more than one scanner loading up the
"document bay"; maybe she has been  advised it won't work.
All very interesting gremlins that I hope some knowledgeable IT people on
the list can throw informed hypotheses on.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]