[Top][All Lists]

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

Re: [Gnumed-devel] further test importing

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] further test importing
Date: Sun, 12 Mar 2006 18:10:59 +0100
User-agent: Mutt/1.5.11+cvs20060126

On Sat, Mar 11, 2006 at 07:30:33PM +0800, Syan Tan wrote:

> I have the impression that gnumed is quite able to handle the import of legacy
> progress notes for non-trivial numbers of records, and have usable load speed 
> when opening large
> emr data within a large set of emr data.  The speed on browser tree load can 
> be brought down to less
> than 4 seconds, even with an emr entity who has had weekly or fortnightly 
> entries for 5 years.
4 seconds is perhaps usable for a limited time but it by no
means acceptable. I do think there's room for improvement.
The way the tree loads data is fairly abysmal. It should
make more use of caching, on-demand loading and backend-side

Same with the journal. The data access code needs overhaul.

> One problem is that switching between the emr browse tree and the 
> chronological text view
> loads the data each time,
> which makes it slow flicking between the two. this might be a bug, because I
> had the impression there is a cache in the main business object, 
> gmClinicalRecord .
There is but it isn't used for the journal afaik.

> I was wondering if it would be fruitful to continue load testing gnumed by
> importing other data,
Yes ! Please do !

> specifically image data, historical test results, historical script medication
> data, vaccinations done,
> letter documents in rtf format ;  which ones are ok to continue with,
> and which tables ( are likely to be stable
> and are worthwhile importing to within the current useage plans) ?
I would think:

images -> blobs
letters -> blobs
test results -> measurements tables
vaccinations -> vacc tables

Those are very likely to be quite stable.

> I was thinking if the
> import procedure is made straight forward, it might get more people involved 
> on
> the au side as it would prove gnumed capable of handling real and legacy data 
> loads, at
> least from an au point of view. 
Sounds very reasonable !

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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