Re: Comments/views appreciated...

"Duncan Langford" wrote
[snip]
>
> So I would be very interested indeed in your learning your current views
> on
> the relevance of 'professional issues' or 'ethics' to your professional
> practice. Do please take as much or as little space as you need, and bear
> in mind that (I hope!) tomorrow's professionals may well be reading what
> you say; negative as well as positive opinions are very welcome.
>
[snip]

The 'professional' title is suspect from the start, since unlike other 'real professions' (medicine, engineering, accountancy...) where a specific type of licensing is required, which can be suspended or revoked for improper behavior (behaviour?) does not exist. This fact makes it necessary for programmers, designers (architects?), and systems analysts to be even more diligent in their work, because there really is no 'controlling authority' to look over their shoulder, except that which may exist within their company.

But, this exposes a critical truth... Don't bite the hand that feeds you.

Case in point...

In the U.S. medical environment, getting paid is a constant headache for physicians. Unlike in most of Europe, doctors must create and submit a valid claim before payment is rendered, especially if the payment is expected from a 'third-party' insurance company (or Government program.) To further complicate things, it is possible in some specialties (like Radiology) to 'split-out' reimbursement for certain procedures between that which is paid for the equipment (technical component), and that which is paid for the Physician's professional interpretation of the study (professional component.)

I was the designer and programmer for a medical billing application in the late eighties and early nineties which was in use by a Radiology 'Imaging Center' in California. The administration of the center was to be paid for the technical component amount and the Radiologists were to be paid the professional component portion. Each individual procedure carried its own split-out amount (expressed as a percentage.) The requirement was to produce a report each month that tabulated all payments reported as deposited in the bank, and break-out the separate dollar amounts that applied to the Physicians, which was then used to calculate their pay checks. Keep in mind that these percentages were all potentially different and that they were based on the original charge code used to bill the original claim to the insurance company, (and they changed annually!)

Ok, you say, no big deal. As long as there is a place to store the percentage to apply and the payments are recorded against each individual line item (they were) then it's a simple calculated report, right. Except that it was a common problem that some payments would be received without clear indication of whom the patient was and/or which line item(s) was/were being paid. In order to get the money in the bank, it would be posted temporarily to a catch-all account in the system called 'unidentified payments' so that the deposits reported would actually match what went into the bank. Problem, there is no charge code to apply the percentage payment against until the payment is actually posted to the correct line item (or refunded), which may take as much as a week.

The calculated report of payments by procedure could not apply a percentage to these payments until the correct line item was established, so in one month the total payments listed on the report might be a bit lower than the total reported (by a few hundred dollars), but the next month the total reported would be a bit higher (again a few hundred dollars.) If examined over an extended time frame (annually) these amounts cancelled each other, but it would never match the actual deposits 'to the penny.' This report was being presented to the board of directors which was entirely populated with Physicians. The first time the report was presented, it was discovered that the total did not match the other financial reports relative to deposits in the bank. The entire report was then suspect, because 'it didn't tie-down to the bank's numbers.' It was explained to them, that the situation did not allow for unidentified carry-over between reporting periods, but they could not accept this.

So the solution as I implemented it, was to pre-process the payment report to discover what total it would report and compare this to the known static figure for total deposits to the bank. The value of the highest reported line item would be stored in memory during the pre-process step. The reporting program would then 'adjust' this highest dollar item (up or down as necessary) and then produce the report which would now total exactly to the amount of the deposits. This was never actually correct relative to the payments-by-charge-code requirement of the original specification for the report. But in order for it to be accepted as accurate, it had to be modified to match the more arbitrary total deposit figure.

Two distinct needs were competing with each other, when they were really separate things; the amount deposited in the bank last month, versus the amounts paid last month that could accurately be reported against an actual charge code percentage... These were almost never the same figure, but the fight was simply too difficult to conduct - once I realized that they would never understand, 'fixing' the report was easier to gain the trust needed to encourage its use. The report that was actually correct, was considered by them to be wrong, so a purposefully incorrect reported was accepted as correct because it matched a tangentially verifiable number.

I could have mis-reported the figures as low in every period and skimmed the difference into a separate bank account; but that would have been unethical.

Way too long (sorry)

BFaux- Received on Mon Feb 13 2006 - 20:04:12 CET