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

[Karsten Hilbert]

> -items that in GnuMed's other tables (appointments, procedures, other 
> services) form the basis of "billable items" would either as part of 
> being committed, or as part of a later batch process, access the 
> XML-RPC in order to write records into a "billable items" table. The 
> individual billable items, having been written, could be automatically 
> or manually updated, UNTIL the time that a responsible user (typically 
> doctor for clinical work, office staff for administrative work) "okays" 
> for the actual charging to be done.
This is a nice generic description to which no one in her
right mind can really say no...  So, yes :-)

> - in the black box, we have a set of tables designed to hold all 
> billing data needs, governed by whatever variety of payer "formats" are 
> defined with freeB.
When interfacing FreeB I would write an XML-RPC server
servicing FreeB calls (FreeB currently queries the EMR by way
of XML-RPC about the items it needs). This "FreeBDataServer"
would know how to get at, say, demographic data via a
Demographic Service defined in GnuMed. Or at clinical data via
the Clinical Service. The FreeBDataServer may well be part of
the "Accounting Service" black box. GnuMed proper needn't be
concerned with that. It just talks to it's "Accounting
Service", calling things like bill_now(patient_id=xxx). That
be the naive approach I'd take if I were to start
implementation today.

> SQL-Ledger is unlikely to already contain a table 
> set that could handle the detail and complexity of patient billing.
Agree.

> I still have to get my head around the fact that different installations 
> of GnuMed will be served by different payers having varied data 
> requirements so how to accommodate that in table structures, unless 
> payment fields are not at the table field definition level, but are 
> drawn from stored values INSIDE table fields...
That's one way: storing structured data, say, XML, in one
content-agnostic field (of type text or bytea). Another, IMO
more appropriate way, is to store field_name/value pairs as in
form_data. Tables could roughly look like this:

create table billing_field_value (
    bill_type,
    id_patient,
    field_name,
    field_value
);

> - freeB would be deployed *INSIDE* the black box, yes?
Hm, in a way, yes. The GnuMed frontend would tell the
accounting service: "record this item for that patient". Later
on, it would say "bill this patient now". The accounting
service would then talk to FreeB to process the bill. So, no,
the general frontend wouldn't be talking to FreeB in which
sense FreeB would be inside the black box. OTOH, the accounting
service would be part of the GnuMed *suite* so, "GnuMed" would
indeed talk to FreeB - inside the accounting service black
box.

> - inside the black box it would be a shame to re-create general purpose 
> tables if already provided by SQL-L to handle non-patient billing and 
> accounting so is it proposed that SQL-Ledger (SL) live inside the black 
> box?
The accounting black box core would *interface* SQL-L in any
way it chooses. This wouldn't concern the rest of the GnuMed
frontend in any way. So, to the rest of GnuMed SQL-L would
appear to be inside the accounting black box. However, the
accounting service would likely talk to a generic stock
installation of SQL-L. SQL-L isn't really *inside* the box.

> - I guess my main question / concern is if SQL-Ledger is to be 
> encapsulated in and accessed ONLY through the "account service" black 
> box does that render any of the SQL-Ledger user interface and 
> functionality inaccessible or exceedingly difficult to leverage its 
> functions of handling non-patient billing, posting invoices and doing 
> the general purpose accounting?
No, not that I can see, unless one deliberately wants to do
that for various reasons.

> Can 
> it be partly-inside and partly outside the box, for example any of the 
> tables from which SL would draw PATIENT billing information would only 
> be access through the black box XML-RPC?
Surely.

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