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

[Jim Busser]

On May 14, 2004, at 5:46 AM, Karsten Hilbert wrote, essentially:
> SQL-Ledger having been written in PERL cannot be extended to call gmPG 
> unless PARROT turns out to be the magic bullet.

> Eventually, one "account service" black box [accessible by XML-RPC] 
> 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.

Could it work this way:

-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.

- 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. SQL-Ledger is unlikely to already contain a table 
set that could handle the detail and complexity of patient billing. 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...

- freeB would be deployed *INSIDE* the black box, yes?

- 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?

- 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? It is supposed to be doing payroll soon 
and so I cannot help but to think that to lock it fully inside an outer 
box on account of patient-related billing is overly constraining? 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?

Previously, Dieter Simader of SQL-Ledger (not on this list) wrote:

> We recently worked on a project in Austria where we integrated a CRM 
> with
> SL entirely from within the backend. If the software uses a SQL server
> (Oracle, Postgres, DB2 or any other SQL server except mySQL) the best
> solution is to make software speak to each other in the background.
>
> Last year we worked on an integration with a medical billing system for
> EMR and translation services. The billing was all done in another 
> program
> and SL provided the means of formatting a consolidated bill from data
> which was sent to the server.
>
> We have used this technology for some time now and I believe it is the
> best solution we found for integration. Most software packages have an 
> API
> but sometimes it is just to cumbersome to use these facilities.
>
> SL can also serve as the frontend for third party modules which will 
> not
> affect the core accounting modules. I structured the software in such a
> way that you can make something else out of it.  This then gives you
> instant access to the backend and functions to perform other tasks like
> posting an invoice.