As a patient, how do I know that my consultation details (demographics,
medicare no, Items claimed, etc) are not being harvested at the POS by
an Insurance Company affiliated with the bank?
mario
Oliver Frank wrote:
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?)
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
