[Gnumed-devel] GNUmed future billing concepts 'invoicing' and 'billed'

[Busser, Jim]

Presently, 'invoicing' involves

- selecting items within the current patient only, and

- actioning to 'invoice selected items'

which requires the existence of an address to which to 'address' the invoice.

Some thoughts:

1. A 'Select all' button, positioned between 'Remove' and 'invoice selected items' might be helpful

2. Does the constraint of requiring an address risk to reflect overly-rigid thinking? Scenarios:


1. I have a patient who does possess a stable address, however she reports that her step brother had tried to have her killed and so does not wish her address to be on record. She has provided me her email address and her cel phone address. If I do need to invoice her, I can arrange for her to pick it up, or I can email it to her.

It seems to me that users should be permitted to generate an invoice without a street address. Of course, the user should be helpfully warned and should have to occur that they actually wish to do this.

2. I have had patients who live outdoors, or in shelters. A few of them would be willing to pay something, when they can afford it. Others may be in a position where some other charitable agency is willing to cover some or all of their charges. This presents two scenarios:

(a) same as in (1) -- that it may be relevant to print an invoice without requirement for an address, or

(b) it may be helpful to be able to designate, within GNUmed, some responsible party (payor) other than the patient. This can be a family member, or a friend who exists in GNUmed, or it could be a non-person such as an organization, such as an insurer


GNUmed-future might therefore benefit from:

- in Demographics plugin, a new tab 'Payers' functioning somewhat like names and addresses:
        - support to add one or more items
        - support to designate one among them the 'active' value
        - support for a comment field

- a link table 'person2payer'

- a trigger added to dem.identity which auto-appends a self-record to 'person2payer'

- the ability to designate, within the Demographics > Payers tab and inside the list of Payers, a value which can represent the pk of a person *or* the pk of an org

- in the Billing plugin GUI, to insert and display at bottom left the patient's default Payer (borrowing space from the Comment), and providing the functionality to be able to alter or redesignate the payer

- the capacity for

        Invoice

to have more than one meaning. In the case where the responsible payer is a person, then billings can be attached to a bill, and a paper invoice generated.  However when the payer is an org, it would be helpful of a click on

        Invoice

would instead approve the selected item(s) to be handled conditionally as follows:

- if there is no instruction otherwise (i.e. in the situation of a default), a paper invoice would be directed to the

        organization
        org contact person
        org address

because some patients might own a business, or be incorporated, or because even an insurance company may require some kind of original invoice.

*** HOWEVER *** if it is possible, in the case of one or more orgs, that they can receive multi-patient billings electronically, then the org can be configured as to which script or service or daemon is to be used, and the effect of "Invoice" will be to add the selected billings to whatever is the next batch applicable for the script or service or daemon.

-- Jim
_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
https://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

On Sat, Jul 07, 2012 at 05:23:01AM +0000, Jim Busser wrote:

> Presently, 'invoicing' involves
>
> - selecting items within the current patient only, and
>
> - actioning to 'invoice selected items'
>
> which requires the existence of an address to which to 'address' the invoice.

Only the final step of creating a PDF requires an address.
You can create a bill just fine without one.

> 2. Does the constraint of requiring an address risk to
> reflect overly-rigid thinking? Scenarios:
>
> 1. I have a patient who does possess a stable address,
> however she reports that her step brother had tried to have
> her killed and so does not wish her address to be on record.
> She has provided me her email address and her cel phone
> address. If I do need to invoice her, I can arrange for her
> to pick it up, or I can email it to her.

- use a fake address, perhaps even of type "fake"
- use the praxis address
- use the address of McDonalds across the street
- use the address of a relative to which to mail it
  with whom she can correspond in any way she wishes

> It seems to me that users should be permitted to generate
> an invoice without a street address.

That will not be a legally actionable invoice in many if not
most countries. Now, legal requirements aren't always
compatible with reality. See above.

> 2. I have had patients who live outdoors, or in shelters.
> A few of them would be willing to pay something, when they
> can afford it. Others may be in a position where some other
> charitable agency is willing to cover some or all of their
> charges. This presents two scenarios:
>
> (a) same as in (1) -- that it may be relevant to print an invoice without requirement for an address,

- invent some sort of address
- use the agency's address "on behalf of"

> (b) it may be helpful to be able to designate, within
> GNUmed, some responsible party (payor) other than the
> patient. This can be a family member, or a friend who exists
> in GNUmed, or it could be a non-person such as an
> organization, such as an insurer

I will not implement further billing functionality in the
foreseeable future.

As far as care is concerned, yes, that will eventually be
helpful.

All this awfully sounds like the requirement for using a
billing application.

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

_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
https://lists.gnu.org/mailman/listinfo/gnumed-devel

[Sebastian Hilbert]

Some parts of this message have been removed. Learn more about Nabble's security policy.

On Saturday, July 07, 2012 09:39:37 AM Karsten Hilbert wrote:

> On Sat, Jul 07, 2012 at 05:23:01AM +0000, Jim Busser wrote:

> > Presently, 'invoicing' involves

 

...

 

> > (b) it may be helpful to be able to designate, within

> > GNUmed, some responsible party (payor) other than the

> > patient. This can be a family member, or a friend who exists

> > in GNUmed, or it could be a non-person such as an

> > organization, such as an insurer

>

> I will not implement further billing functionality in the

> foreseeable future.

>

 

To put this in perspective for future reference. It still is believed that actin on billable items (e.g. producing an invoice) is best done outside GNUmed.

 

GNUmed will make sure it delivers any information it can to said third party application so *that* application has every information it needs to *act* on the provided billable items.

 

This means Karsten decided not to allocate more of his ressources to this problem for now. This however does not mean he cannot be asked for providing help to anyone else extending the current functionality.

 

So if anyone wants step in please do so.

 

@ Jim. Thanks for making us aware of the current limitations. Please file this with launchpad as wishlist bug as it certainly is important.

 

I wonder if we are in a state where we should contact the folks from ledgersmb once again.

 

Sebastian

_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
https://lists.gnu.org/mailman/listinfo/gnumed-devel

[Busser, Jim]

On 2012-07-07, at 12:39 AM, Karsten Hilbert wrote:

> Only the final step of creating a PDF requires an address.
> You can create a bill just fine without one.

I agree any and all bills *could* be handed over to some external application. Payer preferences would be more-appropriately created and managed in the *external* system. I had overlooked, until I more closely examined the schema, that each billed item has a

        status (default 'new')

updatable by the exporter to some suitable alternate value. GNUmed can tolerate co-habitation of

        some bills directly invoiced
        some bills exported

by user selection of which items to directly invoice, and the exporter should exclude items which have been already-invoiced. Users who made a mistake would need their IT praxis support to make the correction.

Each iteration of an exporter 'run' could be documentable as a row in

        bill.bill

thereby achieving a record of when affected billed items were exported. As far as values for

  fk_receiver_identity
        fk_receiver_address
        fk_doc

- fk_receiver_address could be a representation of the external program as an 'org' (maybe same as praxis address with suitable comment).

- fk_doc could reference any exported data file which had been written to disk.

??

-- Jim




_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
https://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

On Sat, Jul 07, 2012 at 03:53:34PM +0000, Jim Busser wrote:

> > Only the final step of creating a PDF requires an address.
> > You can create a bill just fine without one.
>
> I agree any and all bills *could* be handed over to some external application. Payer preferences would be more-appropriately created and managed in the *external* system. I had overlooked, until I more closely examined the schema, that each billed item has a
>
> status (default 'new')
>
> updatable by the exporter to some suitable alternate value. GNUmed can tolerate co-habitation of
>
> some bills directly invoiced
> some bills exported
>
> by user selection of which items to directly invoice, and the exporter should exclude items which have been already-invoiced. Users who made a mistake would need their IT praxis support to make the correction.
>
> Each iteration of an exporter 'run' could be documentable as a row in
>
> bill.bill
>
> thereby achieving a record of when affected billed items were exported. As far as values for
>
>   fk_receiver_identity
> fk_receiver_address
> fk_doc
>
> - fk_receiver_address could be a representation of the external program as an 'org' (maybe same as praxis address with suitable comment).
>
> - fk_doc could reference any exported data file which had been written to disk.

Sounds like nicely imaginative use of what's there, yes.

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

_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
https://lists.gnu.org/mailman/listinfo/gnumed-devel