Jeez. The hits just keep on coming. My email client fritzed out and
corrupted/truncated the message I intended to send. Here is the correct
message. Please ignore the previous one.
>> In any case, having a unique data type for dates precludes the value from
> being treated as anything other than a date. One can't do math on a VFP
> date value and get a result that can be interpreted as currency, unless one
> is completely clueless as a programmer.
(ldEndDate - ldStartDate) * lyPenaltyPerDay = lyResult in currency
(ldEndDate - ldStartDate) is the relevant calculation here. That's where
the math is being done on date values. The rest is math on ordinary
numbers. Of course you can multiply any number by any other number and call
it currency. (Heck, in C++ you can multiply single characters by other
single characters and get a numerical result--if you don't know what you're
multiplying.) Of course, if the result has more than two decimal places it
can't actually BE currency but you can call it anything you want.
Apparently, though, I failed to communicate. :)
If one uses a unique date type to store dates instead of making special
cases for ordinary integers or strings of digits, and then names one's
variables to indicate they are dates, then unless one is completely
clueless one is not going to assume that the result of math specifically
and only on those variables is going to be currency. If one doesn't name
date variables to indicate they are dates, I would submit that one is also
completely clueless.
> And as I understand it, some of the big-iron database systems are
> beginning to offer unique date data types now.
>
Which ones? Oracle, DB2, Ingres, Postgres have had data types since the
Pleistocene.
DATE data types are fairly rare in the industry; most are DATETIME, as
there are often needs to store the time as well as the date. This wasn't
such a good idea, imho, because it makes date math (that nearly EVERYONE
needs) really unpleasant.
Right. I was referring specifically to DATE types, not DATETIME, and I
can't recall specifically what I read but I am pretty sure that somebody
posted something on this list within the last 6-8 months or so about a
big-iron database getting a DATE data type.
Meanwhile, in the situation described, a user entered a date value into a
> control that was intended to accept medical service co-payment dollar
> values. Based on how much this ended up costing, I would guess the user did
> it over and over and over, and the values were added up over time. If so,
> it strongly implies that the user interface was poorly designed, since
> users typically don't make the same mistake hundreds of times in a row.
>
No, they typed the date June 17, 1957, by typing one number after the
other, just as you would enter a date, 6171957.
The error reported was 6,171,957 dollars. Coincidence?
Okay. We are talking about the software that was used to submit a bill
here, not the software that processes bills for payment. But since I raised
the issue of formatting/masking/validation, I'll continue to the bitter end.
1. Wouldn't one associate only pretty recent dates with co-pay amounts?
Presumeably you would enter a date of service on which the co-pay was paid
or came due. Assuming the user had an actual date in mind to enter and
wasn't just fat-fingering gibberish, than June 17, 1957 could only be a
birthdate in a medical billing context. It could not be a co-pay date for
data that was entered during the period audited. Medicaid didn't even exist
in 1957.
So, why was the interface designed such that a data entry operator could
confuse a birthdate with a date of medical service? One-time patient
demographic data entry should be completely separated from many-to-one
service records in the GUI.
2. In any case, I continue to maintain that the system should have applied
a limit on the number of pre-and-post decimal digits that could be entered
for a co-payment, and, perhaps, used a picklist of acceptable values for
the service type being entered. This would have made it impossible for a
user to make such an error.
Once again, I'll note that in this case, the error WAS caught and FLAGGED
by the software. It was the decision of the agency doing the processing
that they would rather pay the wrong amount and catch the problems in the
audit, than flag a large number of entries and have to manually review
them. The audit did catch this issue along with thousands of others, and
managed to collect back nearly all of the money. In the first pass, they
lost 7.8 million out of 25-ish BILLION, 99.7% accuracy, and recovered
nearly all of that in the audit phase.
All large scale processed (178 million claims processed) need auditing and
monitoring. It did its job. It identified problems (the audit department
notes the problems had been noted and improvements recommended). If you
read the audit report, all the way to the end of the 22 pages, you'll see
the system worked, the money was recovered, the screw-ups made the
newspaper, the 99% first-pass accuracy was followed up with 90% recovery of
the remainder. The perfect is the enemy of the adequate.
From the report: "For example, many claims we reviewed were subjected to
the eMedNY edit "Medicare/MCO Payer Amounts Not Reasonable." However, the
edit was "set to pay" (as opposed to pend or deny) a questionable claim. If
this edit was set to pend or deny payment, eMedNY could have prevented the
aforementioned overpayment (totaling $6,171,957) when a date was entered
into the field designated for a copayment."
This certainly implies that the software had a user-configurable setting
for what happens when a questionable claim comes in. Let's ASSuME that's
true and not that the behavior was in fact hard-coded.
Why would such software be designed to automatically pay ANY invalid or
questionable claim without prompting a review by a human first? How is that
good design?
Ken Dibble
www.stic-cil.org
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/5.2.1.1.1.20130217122537.01fc0...@pop-server.stny.rr.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
