Greg Twyford wrote:

Having finally caught up with this I also wonder how bulk-billing doctors get any surety or feedback about claims being accepted or not.

From what I have been able to understand so far, I imagine that it will be like the current Medicare Online Claiming, when that is used in real time mode (which I hope that most users are doing). I presume that the EFTPOS-based system will tell the user immediately if the Medicare system thinks that there is some reason to reject the claim.

Your analysis has raised many good points, especially the cheque issue if the practice doesn't get paid up front.

Also one of the set of keystrokes is obviously the item number, so there is lots of potential for data entry errors, and there is no information about how they'd be handled. Do you need the patient to swipe their card again, as its obviously the confirmation that the patient is involved in the process?

You will see from the Medicare Australia page that I quoted that:

- for bulk billing one swipe of the patient's Medicare card is needed;

- for "paid patient claims" (referring to fully paid), the patient first pays, which may involve swiping their credit or debit card, then they swipe their Medicare card, then to get the Medicare benefit, they have to swipe a *debit* (not a credit) card - that's three swipes. Apparently the fees on credit card transactions are too high to be acceptable, so the patient has to have a debit card;

- for "unpaid accounts", it's just one swipe of the Medicare cards.

What is missing from this list is where the patient pays the gap or some lesser portion of the bill: this is neither a "paid patient claim" nor an "unpaid account" as described on the Medicare page. Presumably the patient pays the gap, possibly by credit or debit card (one swipe) and then swipes his or her Medicare card to get the Medicare benefit cheque generated (2 swipes).

More importantly, there is no information about how any data gets into the practice management system for things like accounting, chasing up patients re unpaid accounts, dividing up the rebates by whatever formula or arrangements the practice has in place, etc. All re-keyed into the PM system or done by hand, without the benefit of those DB4 copies a manual billing practice keeps?

The whole process seems blind to those implications for practices, which would presumably require re-keying.

The Medicare page seems to announce almost proudly that the EFTPOS system will stand alone, which does mean that practices will have to key the transactions twice.

Patients seem to get receipts but not the practice, and who pays for all of that lovely paper coming out of the eftpos printer?

Whoever pays now - I'm not sure. Maybe I should know, since I am a partner in a practice. I think that the bank supplies the paper as part of the deal.

I also wonder where the consultation with practices has come into this whole process. Missing as usual?

Good question. Julia Nesbitt of the AMA, with whom I have been having a vigorous debate about the proposed new system, and who I have copied in to this message, may be able to tell us which medical practices have been involved in the development of the EFTPOS system.

As I've said before, the government wants a technology to smooth the path away from bulk-billing for many Australians.

Only if they can do it in a way that prevents their opponents from portraying them as being anti bulk billing or as acting to reduce bulk billing. I am amazed that the Labour party has not screamed loudly about the 90 day unpresented Medicare cheque scheme, which really has helped practices to be able to reduce or stop bulk billing. (Is there anybody's practice on this list that is not on the 90 day unpresented cheque scheme, and if not, why not?)


--
Oliver Frank, general practitioner
255 North East Road, Hampstead Gardens, South Australia 5086
Phone 08 8261 1355   Fax 08 8266 5149  Mobile 0407 181 683
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk

Reply via email to