gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] billing by GnuMed / TORCH / OSCAR
Date: Thu, 13 May 2004 19:38:07 +0200
User-agent: Mutt/1.3.22.1i

Jim,

it seems SQL-Ledger might be a good choice for the generic
billing side of things.

I am fine talking to the SQL Ledger schema directly. After
all, a schema in an RDBMS *is* an API, and a fairly accessible
one at that. So, IMHO we should leverage SQL Ledger support
for *multiple currencies, *transaction tracking, *best
practice accounting logic etc (*cross out where appropriate).

There's one thing to know about "supporting PostgreSQL". If
one comes from MySQL and "now also supports" PostgreSQL in most
cases it will be that "it now also works with" PostgreSQL
instead of "leverages the full power of a truly dependable
RDBMS like PostgreSQL" (or Oracle, DB2, for that matter).

As long as things "just run" on PG it doesn't much help. One
should leverage views, stored procedure, foreign keys, various
kinds of indices, check constraints, triggers and rules to
ensure utmost reliability. This is more akin to an
implementation on a given database engine as opposed to a port
to one. Yes, it is more work to support several then.

> 1. Regardless of backend db tailoring, is it obvious that for any of 
> OSCAR, TORCH and GnuMed to implement freeB would benefit from a shared 
> table design? Is it therefore worth my joining a TORCH list and/or for 
> someone who knows Tim to make an introduction in order to pitch the 
> proposal? 
I would certainly vote for using (not *re*using !) the SQL
Ledger tables.

> 2. If there is to be a table design, and if the tables are intended 
> down the road to be accessed by SQL-Ledger, I am thinking it make sense 
> to get SQL-Ledger input during the conceptualization and table (and db) 
> design stage, even if the implementation may not happen for some time? 
IMHO the other way round. SQL L is a generic accounting
package. Medical billing is one instantiation of generic
billing (if a devilish one). Hence GnuMed should write into
SQL L tables. We may have to add some tables to support
certain data that just don't fit in with the generic side of
things.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]