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: Jim Busser
Subject: Re: [Gnumed-devel] billing by GnuMed / TORCH / OSCAR
Date: Fri, 14 May 2004 09:53:10 -0700

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.





reply via email to

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