On Thu, Sep 14, 2006 at 05:08:11PM +0800, Syan Tan wrote: > just wanted to report gnumed was able to handle the import of 14626 patients, > records upto 7 years old, documents and progress notes, using up 4.2 G ; Nice ! :-)
> import process with 2 computers ( ~ 1.8 MHZ each ) , across 100Mbit link, > about 14 > hours. Do you have any idea where there might be bottlenecks, particularly those which we can do something about ? Speeding up this process, perhaps selectively on a per-patient basis, might allow frequent on-demand (before offsite work, that is) updates of (part of) the data ... > The private use is as portable read access to medical records when doing > offsite consultations, > so not just relying only on memory when consulting . Excellent. You scratched an itch. This use case now obviates that it will now be mandatory to follow a different policy regarding schema changes: The v2 schema (as per 0.2) will be the bottomline. From there onwards SQL *change* scripts ONLY will be allowed to modify the database such that installing v3 will mean - install v2 - upgrade via scripts in server/sql/v2-v3/ upgrading vX to vZ will mean - clone vX - upgrade via scripts in server/sql/vX-vY/ - upgrade via scripts in server/sql/vY-vZ/ etc That way we can ensure perfect data integrity (process-wise) without any loss cross-upgrade. > Although password protected, > will need to > also look into encrypted file system at some stage. If I were a software company hawking GNUmed to doctors (hint hint) I'd create a private table space for the gnumed database from within PostgreSQL and put that tablespace onto an encrypted partition. That partition would be available only after mounting with the proper passphrase. Thereafter it'd be available to PostgreSQL transparently. dm_crypt and friends offer such things. > - hoping not long before gnumed could verifiably claim to be a proper > open-source > alternative or adjunct for gp emr use in au. Syan, may I ask for the following: The current importer makes a couple of compromises which we decided on on-list regarding where to store what type of data. Would you please observe what data you access often and would like to have available in a cleaner way (say, social history or whatever). Then please do report that on the list and we will work on getting appropriate tables done for those things. I am hoping a bit on "addictive adjunct", BTW. Thanks, 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
