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

[Karsten Hilbert]

Hello Chris,

I'm sure you've found this link already:

        http://wiki.gnumed.de/bin/view/Gnumed/Billing

Going from there you'll find a bunch of musings on the subject.

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

Not really or rather only for some values of "solve".

Those three solutions are but crutches upon which GNUmed
limps along. Especially the latter doesn't really work
except for the singular case where you'd send the very same
bill to all patients (except that each bill contains another
receiver :-)

So, no, I wouldn't consider this solved in any significant way.

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

We've got *none* of that happening as yet. Yes, one should
have it happen to see how the clinic goes.

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

Only printing the the "fixed", unchanging bill via a LaTeX
template (after all that's nothing but a letter template
where we replace but the demographics ;-)

> >> 3)  What are your biggest headaches currently?  What can be done to ease 
> >> them?

> >        privately-insured patients
> >
> > 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.

The plan here is to make it easy for the doctor to

- invoke a function "register billable item right now"
  whenever convenient - some of this might happen
  automatically linked to the hooks framework

- select the billable item in question - this might be as
  simple as selection from a list of billables - of which
  GNUmed knows no further details at all but which are
  identifiable by the eventual bill generator, for this it
  may be convenient to (say periodically) query the bill
  generator for billable items and repopulate the GNUmed
  list such that maintenance only needs to be done in one
  place

> 2)  I'd set up GNUmed and LedgerSMB into separate schemas

Databases, in PostgreSQL speak, that is ?  Or do you think
of using the same database but separate schemata ?  If so,
no problem, GNUmed would support that just fine - except
that, maybe, doctors may not like the billing software to
access the GNUmed patient database just so due to privacy
concerns.

> with a third import schema.

We already have a "bill" schema which can be used to collect
per-patient billed items selected from billable items.

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

Or on demand. Doctors like to (be able to) be in control :-)

> All mapping of how something is billed
> would occur in that import schema.

You mean, say, matching up GNUmed-selected billed items with
billing-app-side billable item details ? (like what I hinted
at above)

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

Yep, that's sort of what I thought would need to happen on
the billing app side.

> So my thinking is a set of three schemas (or even separate db's if
> necessary) like:
>
> GNUMed
>  |
>  |
> \/
> Processing ----> billing gateway
>  |
>  |
> \/ Accounting (LedgerSMB)

I would, perhaps, run a tightly controlled script reading
from the GNUmed "bill." schema transferring data into the
"Processing" database (wherever that may live).

That script could be run on user demand and/or invoked by CRON.

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

Any way is fine as long as GNUmed can associate an invoice
number with a bill for a patient.

BTW, there also needs to be a way to know which billing
items have (technically) successfully been turned into a
bill (regardless of whether there's any financial turnaround
just yet) so that GNUmed can remove those from its "bill."
schema. Very likely this should be done by the script moving
(rather than replicating) billed items from its "bill.*"
tables.

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

Yes, just like I said above :-)

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

Absolutely.

> However, one could set up views pulling data from LSMB and
> provide maybe some sort of add-on to do this within GNUmed.

We'll see. Certainly not that important for a first
implementation.

> Does this sound entirely insane?

Definitely insane enough to warrant scratching this
itch the open source way :-)

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

Great !   Please do keep us posted on your progress and
perhaps any problems you may encounter. There just *may* be
a tiny need of explaining a few terms for your father to get
the gist of the GNUmed EMR:

Encounter:

        Whenever the health care provider interacts with the
        eChart, either with patient or without patient. Not
        *quite* identical with the North American concept of
        "billable encounter".

Health Issue:

        Foundational illness a patient suffers from, say,
        arterial Hypertension or Diabetes mellitus Type 2.

        Issues can be active or inactive.

        Issues can be clinically significant or not.

Episode:

        *Period* of *activity* of a Health issue during which
        it requires care, say, when the patient is actually
        seeing the provider for his Diabetes or Hypertension
        because it is out of control.

        Episodes can be open (ongoing) or closed (finished).

        There can at any one time only one open episode per
        Health Issue.

Problem:

        A list showing *active* Health Issues plus *open* episodes.

Maybe this is a good introductory read:

        http://wiki.gnumed.de/bin/view/Gnumed/BasicEmrConcept

All in all it's all here:

        http://wiki.gnumed.de/bin/view/Gnumed/GnumedManual


Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346