Beaverlog Tips: Volume 40 - February 25, 2008
Refunds, Bounced Checks, and Charge Backs
Once you have entered a payment into The THERAPIST, a variety of things can happen that can cause you to want to remove or reduce the amount of the payment. The most obvious is if you made an error when you entered the payment but while correcting errors is not the topic of this article, some of the same principles apply. This article will discuss what to do and not do when you have to issue a refund, when you receive and enter a payment from a check that bounces, or when a patient pays with a credit card and later charges back the payment with their credit card company.
In all of these situations, you could just delete the payment but that is a bad idea for several reasons. The most important of those reasons is that deleting the payment would leave you no "paper trail" of what happened. Of course, in this case, it's more a trail of magnetic bits on your hard disk, but it's the same idea: a physical record of the series of transactions and the magnetic bits can be converted to paper by printing a patient ledger or other report. Instead of deleting the payment, you should follow a simple multi-step process:
Now, on the screen, on statements, and on reports, you have a record of what happened and the "why" is in the statement comments you entered. Sure, it takes a few more seconds than just deleting the payment, though not very many seconds, and the benefits greatly outweigh the time spent.
Why is The THERAPIST Slower on a Network than Word or Excel?
We get this question from time to time and it seemed like a good time to answer it here. It's a good question and a simple one but the answer turns out to be less simple than the question.
When you load a Word or Excel document that is stored on another computer on your network, the whole file is read at one time and all of the work on the document happens in memory until you save the file again. Then the entire file is written back across the network at once. Even on fairly large files, reading one time and writing one time are relatively fast though noticeably slower than if the document was on your own hard disk.
The THERAPIST, however, is basically a specialized database program with many, many data files. These data files contain internal indexes called keys that help the program locate information quickly. Unlike a printed index, the keys in our data files are organized in a tree-like structure abbreviated with the crude representation below for an alphabetic key:
A - AA - AAA
Not all nodes are contained in the key, only those that have something to index. If a file indexed on last name had entries for Abbot followed by Arnold, there would be no entries for words before Abbot or anything between Abbot and Arnold. Another feature of keys is that they have levels. The first level of the example key contain A, B, etc. The second level has AA, AB, AC, BA, BB, etc. When a data file is opened, the first level of each key is read into memory but lower levels are loaded only as needed. So if a patient is to be searched by name, the first letter lookup is extremely fast. The results of that lookup tell the program what part of the file contains the rest of the keys on that branch. The lookup is highly optimized but there are usually several to many requests to read portions of the key until the desired entry is found. Once found, another request reads the record sought.
So instead of one request to the remote computer to read the file and one response contain the entire file as in the case of Word, Excel or other non-database programs, a simple lookup can have dozens of back and forth exchanges. And that is in the simplest possible case. More often, information is being requested from many files at the same time or sequentially and there can be hundreds of exchanges.
Whether you are using a true network file server or a peer-to-peer network, when data on one computer is accessed from another computer on the network, the computer that stores the data is acting as a "Server" in that it is serving up the data to "Clients" on the network. In the case of The THERAPIST, this not a true Client-Server arrangement because the intelligence involved in deciding what data to obtain is done at the client end, within The THERAPIST program and not on the server. In this case the server merely behaves as a distant hard disk.
If you have ever walked with toddlers, you know that it is the slowest person in the group that determines the speed of travel. So it is with data over a network and the slowest component by far of most networks is the speed of data over the wires. That speed is limited by two factors, the capacity of the wires, called bandwidth, and the amount of traffic using some of that bandwidth. If you are the only client on the network, yours is the only traffic but if many users are using the network, even for different purposes such as surfing the Internet, you have to share bandwidth and this slowest component becomes even slower.
Bandwidth is not the only resource that is shared on a network. If multiple users are reading and writing data to the same server, the server has to share its time between all of those different requests. That means both processing time and time to access data on the server's hard disk. The hard disk has a little arm that goes back and forth over a series of spinning disks to access specific files and, while it moves really fast, it is still a physical device that takes some time to go from one spot to another and he more requests to read or write data, the longer it takes to wait for your turn.
Thinking again about the number of data requests and responses made by database programs we can now factor in that each request and response on a network has a certain amount of overhead. For example, each exchange has to know who sent it and who is receiving it. There are also error-detection components. When a large chunk of data is sent, the overhead is small by comparison. When the exchanges are small, such as most of those used by The THERAPIST, the overhead is relatively large.
A simple example sums it up nicely. If you move a hundred pounds of gravel at one time in a wheelbarrow, it is much faster than doing it one pebble at a time.
Free Support Call
We didn't get much response to our recent call for information about which payers and/or clearinghouses (receivers) our customers are sending electronic claims to. That's why we used a catchier title for this than last time. Catchier but still accurate. If you send us a list of who you are sending your electronic claims to, you get your choice of one free technical support call or $30 in Beaver Bucks you can use like cash to purchase support, upgrades, or additional features.
You can also tell us about receivers who were so bad that you decided to go somewhere else.
Send your list, big or small, to firstname.lastname@example.org and please include your customer number.
|Copyright © 1993|