Re: [Gnumed-devel] help with running client

[Karsten Hilbert]

On Thu, Jan 25, 2007 at 10:30:07PM +1100, syan tan wrote:

> I am trying to run the client , using an older database.
That will not work and the client should complain about it,
too.

> Is there a way of knowing which version database is running ?
Yes.

If the hash of the database corresponds to a known version
the detected and expected versions will be logged in the log
file.

If you want to find out whether or not your database is of a
known version and which you can do like so:

- connect to database

- run
        select md5(gm_concat_table_structure());

- compare the hash to the known hashes in
  gnumed/pycommon/gmPG2.py

> Also , how to upgrade from one version to another ; apparently this can
> be done non-destructive of data ?
Yes !  Like so:

- assume schema version 3 is installed in gnumed_v3
- you want to upgrade to version 4, then aptly named gnumed_v4
- go to gnumed/server/bootstrap/
- run
        upgrade-db.sh 3 4

It should succeed. The upgrade process will

- make a backup of the original database just in case
- clone the existing database gnumed_v3 into gnumed_v4
- modify the new database gnumed_v4 to actually become version 4
- verify source and target database hashes to be of the
  correct versions along the way

Safe, eh ?

> I get this error do with configuration 
> 
> With customized clients, presumably use of the backend is preferred. 
> How is it best to add a hook into the demographics search use case, 
> so that an alternative database for demographics is searched and
> displayed,
>  and then when one is chosen, an import is made from the alternate
> database, prior to opening the record in gnumed.
The perfect hook for that is the "external patient source"
mechanism. It is (well, now was) intended for reading in
patient demographics from files exported by legacy apps. It
can certainly be extended to allow for searching an
alternate database.

I would go about it like so:

- write a GUI function that allows selection of patients
  from the legacy source

- we may need to instrument our standard searcher to be able
  to pass in the search term to the external patients source
  mechanism - I'll do that for you if you intend to go down
  that route

- include the new external source among the sources searched
  for in

        gmPatSearchWidgets.load_patient_from_external_sources()

Please take a look and ask again if you need help on
specific points.

> Is the idea of destroying the record in the source database to preserve
> one-copy consistency ?
Well, in a perfect world, yes. But in the imperfect world
that GNUmed tries to cope with this isn't necessary. When
GNUmed receives patient data from an external source it
first verifies whether that patient (name + dob) already
exists and only creates a new one if not so.

> Perhaps this can be optional, because there are
> probably more users just wanting to evaluate another medical record
> system, but not necessarily give up their old one.
Yes.

>       So back import of updated record into the originating database would be
> a good feature, because it widens the number of potential users. ( e.g.
> in a clinic where policy is very conservative, to continue using what's
> known, but there is leeway to use any other
> system that integrates with the original system ).
Well, now that's an issue beyond the scope of simply using
external patient sources. Back-importing updated records or
even only *additional* record data carries with it a whole
host of difficulties - you very well know the syncing issues
involved. Not to mention that we'd need a way for the legacy
system to *import* data. We - as in GNUmed - can certainly
export anything in any way a user needs.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346