[Gnumed-devel] Re: Document for introducing GnuMed (regarding India's project opportunity)

[Karsten Hilbert]

> A question about GnuMed:
> 
>       monolithic database
> there are notes on the list, from Andreas, about problems / 
> limitations to installation of Postgres and/or gnumed's "server" 
> software, something about having to wait until something that is 
> postgres-related is either fixed, or built (I am not sure which). Is 
> this a problem only with installation under Debian, or is it only a 
> problem if wanting to split gnumed's services across more than one 
> database (or server) or is it both? Do we have any idea when the 
> problem could be fixed?
It would be possible to use distributed databases to
physically separate services even now. That would mean we
would have to use the dblink module that is in the contrib/
part of PostgreSQL and not in the core distribution.

Even if we did we would have to rely on foreign keys to link
data across databases. As long as we don't change which
database we access for which information there is no problem
with that. However, doing so is very fragile since our
"services" model is *intended* to link to changing databases
according to some configuration option. The only "safe" way of
doing such is using the same PUPIC for a patient in each
database. I have made several attempts at discussing PUPIC
generation on the list with no conclusive result. Also, in the
field, that problem isn't solved - it is handled in various
places, and FEBRL provides a good framework for doing so but
it isn't solved.

Hence: As long as we don't specify and use a "good" PUPIC I
will not enable distributing data across separate databases.
Others may do as they see fit.

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