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: Karsten Hilbert
Subject: Re: [Gnumed-devel] Introducing myself and questions on billing/accounting
Date: Wed, 18 May 2011 23:40:07 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, May 18, 2011 at 02:24:03PM -0700, Jim Busser wrote:

> I think it's simplest to say that GNUmed does not currently "do" any billing
...
> I would rather say that GNUmed is ready to have billing "added".

That's the correct characterization.

> What GNUmed should next need is
> 
> - a table which can hold billable items

Yes that's the selection list of billable items I was
talking about.

> - for each record in the table
> 
>       1) use-cases for when they would be created;

I would understand this as "would be copied to become a
bill(ed) item" (an "invoice line" in ERP speak).

The billable item list itself would hopefully be
synced/repopulated from somewhere else (say LSMB) where
maintenance thereof is mandatory anyway (because actual
bills are created from that).

>       2) data content specification
>               patient identifiers
>               practitioner identifiers
>               service identifiers

Those three are the bare-bones minimum.

>               who is paying (who is to be billed)

This *could* be done inside the "other end", say LSMB, for
the time being because, for bill generation, it would have
to maintain some idea of bill receiver at any rate,
regardless of whether that information is passed in from
GNUmed or initially maintained within LSMB.

All things considered, a very first implementation could use
a design decision of "always bill directly to the patient".

This is only useful part of the time, sure, but it IS useful
and deployably proves the concept.

> The above needs a combination of
>       A. columns to be added to existing and new tables
>       B. GNUmed plugin
>       C. script or daemon to further handle the billed item
> 
> The last-named (script or daemon, "C") would overlap the proposed gateway. If 
> Chris is interested to lead development of a GNUmed plugin "B" (helped by 
> whatever explanations or debugging help he might need) then I can surely 
> together with Karsten and any others interested provide
> 
>       1, 2, 3
>       "A"
> 
> Whereas if Chris only becomes interested at "C" then we will be in limbo 
> until someone else has sufficient need to develop or to support to get 
> developed "B".

Given enough outside drive and results-producing commitment
I will surely take care of A). The B) really isn't that hard
given Sebastians excellent "my first GNUmed plugin" blog
series. I can surely help with that. Given C exists, and A
has been taken care of such that C *can* exist at all and
all we need is B I think I could attempt to undertake the
bare minimum of B.

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



reply via email to

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