Re: [Gnumed-devel] billing by GnuMed / TORCH / OSCAR

[Karsten Hilbert]

> http://www.gnumed.net/whitepapers/Interacting_with_the_Backend.html
This is a bit misleading. gmPG does not encapsulate the
services per se. It only encapsulates *establishing access* to
them. And this is only valid as long as a "service" is
directly equated with a "database somewhere". Eventually, a
"service" would be a black box with an XML-RPC API (or
similar). It matters little what storage mechanism is there
inside that black box. However, GnuMed isn't currently fit at
all for actually going into such "service" black boxes (apart
from, say, drug reference data) due to the single missing
thing of a working patient ID implementation. Currently we
cross link (whether FKs or not) patient data by primary key.
Thusly we better make damn sure we always talk to the same set
of databases. Only when we can say patient "xxx" always has
the unique, robust ID "yyy" we can start using that ID (where
"ID" may be a set of traits as in PIDS or FEBRL) to poke
around in various disparate databases, eg. look for clinical
data for patient "yyy" in the clinical *services* of Dr.Herb,
Dr.Terry, etc. Or, to be less spectacular, for running
separate, non-synced clinical services at two locations.

Only *then* will *I* contribute to code attempting to connect
disparate datasource (eg. non-monolithic backends). This is
post-1.0 IMO at which time we should actually move to access
real services by XML-RPC (even if we still artificially
constrain them to be connected to one monolithic backend).

> - Would we then be wanting SQL-Ledger to call, through gmPG, to the 
> "accounting related" service listed in
>       http://www.gnumed.net/whitepapers/serviceslist.html
No. Eventually, one "account service" black box would
encapsulate and access an SQL-Ledger installation. A GnuMed
frontend would talk to that accounting service as to any other
accounting service, or, in fact, to any other of the services
in the service collection.

> - Had work been done on an "accounting related" service, or is its 
> current status only at the conceptual design stage (e.g. list 
> discussion including Yudhvir's postings, plus what I have put up as a 
> billing white paper)
no work done, only talk

> - As SQL-Ledger is written in PERL, does that pose any problem for 
> SQL-Ledger to be extended to call gmPG?
Yes. It can't. Unless PARROT turns out to be the magic bullet.

> If it ends up being the 
> SQL-Ledger people who provide this extensibility,
I don't see how we can expect them to do any of that.

>  is it perfectly 
> acceptable that it is done in PERL?
Surely so.

> -  What about the "accounting related" service - can it be developed in 
> PERL by SQL-Ledger people, or might GnuMed want (or need) to develop it 
> itself, in Python?
Either way, as long as it is accessible by XML-RPC.

> - I understand that in order to run efficiently, PostgreSQL needs to be 
> configured,
Configuring PostgreSQL is largely independant of the
applications it stores data for (except for exceptions :)

PG doesn't care whether SQL-Ledger and/or GnuMed and/or any
number of well-behaving applications access it to store data.
That's exactly the *point* of a DBMS.

> accounting databases and tables, is there any potential problem of 
> conflicting configuration requirements?
Potentially, yes. But it actually happening would be a sign of
poor application design.

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