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

[Jim Busser]

Karsten and others:

I contacted Dieter Simader of SQL-Ledger (see below) whose status I was interested to probe relative to medical record software.

I gather that OpenEMR, though it has implemented freeB, is not positioned to collaborate on SQL-Ledger on account of being built on MySQL.

OSCAR's home page now states "support for PostgreSQL". While I do not know how far they have gotten, it opens the possibility at least of a common approach to freeB and later SQL-Ledger. Apparently OSCAR was supposed to implement freeB but did not. I gather the core Ontario programmer who was to have implemented the billing left the OSVAR project and as a consequence the local British Columbia IT people (the same ones who are looking at helping me) were required to quickly take it onto their backs for OSCAR. I await clarification of OSCAR openness to freeB.

Tim Cook on one of his TORCH web pages stated a plan to at least consider PostgreSQL and SQL-Ledger:
http://www.openparadigms.com:9080/documentation/future_of_torch/InfrastructureAndDevelopment

Tim did not reply to an email I sent 2 months ago in which I asked to be put in touch with whoever is developing their billing. Although he  may just have been busy it is also possible that to get Tim's attention someone may have to join the TORCH list, and/or would have to know him already in order to make an introduction.

Questions:

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?

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?

PS I had been aware that Dieter Simader earns his livelihood from SQL_Ledger. I therefore expected in order to attract his attention it could be important to convey willingness to subsidize some of his time, which (at least for consultation) I would be prepared to do.

> > re Medical office interface consultation from SQL-Ledger
> >
> > I am a medical doctor from Canada who, although only knowing the
> > rudiments of coding, am quite familiar with medical doctors' needs in
> > order to get their billing done. I am also a participant in the Open
> > Source medical project GnuMed (www.gnumed.org) which tries to be
> > forward-thinking and to keep attuned to what lies ahead in Open Source,
> > both in other medical software projects (e.g. OpenEMR, TORCH, OSCAR
> > McMaster) as well as projects paramedical (freeB) and nonmedical
> > (SQL-Ledger).
> >
> > I have been tasked to help plan the billing module for GnuMed and we
> > have been thinking to take advantage of freeB to do the formatting
> > required to comply with various health insurance payers, and to use
> > SQL-Ledger to help house and administer the billing data. It is quite
> > possible that my/our needs are in fact in common with those of OpenEMR,
> > TORCH and I confess I would be interested to know if you see it the same
> > way.
> >
> > I have been working on a white paper, to which I would refer you (except
> > that our wiki is down at the moment), but I am looking forward to your
> > reply including whether I could pay you from my own pocket for whatever
> > initial guidance you might like to offer on implementation options and
> > strategies that we might consider. Thank you!

> From: Dieter Simader <address@hidden>
> Date: May 12, 2004 9:26:29 PM PDT
> To: address@hidden
> Subject: Re: Medical office interface consultation from SQL-Ledger
>
> Dr Busser,
>
> 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 too 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.
>
> kind regards,
> -- 
> Dieter Simader    http://www.sql-ledger.com   (780) 472-8161
> SQL-Ledger           Accounting Software       Fax: 478-5281
> ============ On a clear disk you can seek forever ==========