Re: [Gnumed-devel] stats au

[Karsten Hilbert]

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