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 aggregation.
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 ! Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
