gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Introducing myself and questions on billing/accountin


From: Chris Travers
Subject: Re: [Gnumed-devel] Introducing myself and questions on billing/accounting
Date: Wed, 18 May 2011 08:52:56 -0700

On Wed, May 18, 2011 at 1:13 AM, Karsten Hilbert
<address@hidden> wrote:
> Hello Chris,
>
> a hearty welcome to the GNUmed community.

Thanks.


> This is most certainly the way one needs to go about this.
> Medical billing is, uhm, complex. No language I know offers
> an adjective to adequately describe it (or distance oneself
> from it). Insane, perhaps, maybe that's it.

I can imagine.  Seems regional rules for this sort of thing can be
unduly complex even in other industries.
>
>> 1)  What are others in the community currently using in the areas of
>> billing and accounting?
>
> We've got three "solutions":
>
> - patient demographics exchange with local specialised
>  billing program (CA MSVA format)
>
> - patient demographics exchange with (German) legacy
>  "practice management" (== billing) software
>
> - LaTeX template based "fixed bill" printing where nothing
>  but the patient demographics changes between bills to
>  different patients

Now, this solves the billing issue, right?  But what about the
accounting issue?  Even for state-insured individuals, you still have
to track the money that is expected to come in, track against
expenses, etc. if you want to maintain a financial picture of how well
the clinic is doing.

>
>> 2)  How are these integrated with GNU Med?
>
> 1/2) data exchange via standard file format
>
> 3) tightly integrated via our document/forms printing code

This is something supported on GNU Med itself then?

>
>> 3)  What are your biggest headaches currently?  What can be done to ease 
>> them?
>
> Re Germany there's two fairly distinct bill targets that can
> be identified:
>
>        state-insured patients
>
>                Forget about it. interface with a legacy billing
>                solution. Technically it's got nothing to do with
>                bill writing either.
>
>                On this front you may be aware of REMITT and FreeB
>                which are specialized US medical billing engines.

Right.  No need to re-invent wheels there :-)
>
>        privately-insured patients
>
>                Those will need a standard paper bill as can be
>                produced with, say, LedgerSMB.

Ok.
>
> Focussing on the latter I think there's great potential,
> even for Germany (we've had it desired by users). Several
> parts are needed for that (in sequential order of
> happening):
>
> - a place to initiate selection of items to be put on bills
>        - needs to be done in GNUmed itself
> - a place to enable selection of items to be put on bills
>        - either in GNUmed or elsewhere
> - a place to (manually) invoke generation of bill(s)
>        - nice if doable from GNUmed
>        - can be done elsewhere, too
> - a place generating bills
>        - best done in a "bill generator" like LedgerSMB
>        - may need to be able to apply a few rules
>          re deductions for certain patients (but this
>          may be implemented via appropriate billable
>          items, too)
> - a place to print bills
>        - can be done from GNUmed if PDF produced by bill generator
>        - no problem doing from bill generator itself
> - a way to inform GNUmed about the generated bill
>        - bill-as-PDF is fine but do deliver a bill ID
>          in machine-readable format for later querying
>        - so it can store a copy thereof, if the user so wishes
>        - billing solutions may go away/switch/etc but
>          the user will want to keep a copy with the patient

If I were looking at doing this for a medical clinic in the simplest
(least coding) way possible, here is what I would do:

1)  I'd look at what needed to be minimally extended in GNUmed in
order to designate what was billable and how.
2)  I'd set up GNUmed and LedgerSMB into separate schemas with a third
import schema.
3)  I'd use triggers to replicate the interesting subset of data from
GNUmed into the import schema, and stored procedures run, say, nightly
to import data into LedgerSMB.  All mapping of how something is billed
would occur in that import schema.
4)  All invoices would come in as sales orders, could be reviewed by
the billing department and adjustments made as necessary prior to
posting as invoices.
5)  Longer run, would extend one or both programs to include more mapping info.

So my thinking is a set of three schemas (or even separate db's if
necessary) like:

GNUMed
 |
 |
\/
Processing ----> billing gateway
 |
 |
\/ Accounting (LedgerSMB)

Invoice numbers could of course be passed back up this system as well.
 However, it seems simplest here to assign the invoice number in the
processing db than use LSMB's native functionality.

> Now, other things are needed that don't fit in the sequence:
>
> - a way to manage billable items (products, in ERP speak)

I think this would have to be done primarily in LSMB with some mapping
available to GNUmed.

> - a way to keep track of invoice status
>        - nice if queriable/query-invokable from within GNUmed

For a first phase, the easy thing to do would be to do this in
LSMB....  However, one could set up views pulling data from LSMB and
provide maybe some sort of add-on to do this within GNUmed.

Does this sound entirely insane?

I think my next phase is going to be to install the software, and have
my father who is a physician go over the use cases with me so I have a
better idea of what mapping needs to be done.

Best Wishes,
Chris travers



reply via email to

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