[The following is a transcript of the speech given at the May '98 MTIA meeting in San Diego by Jeremy Wells, Acting Chairman for ASMART]
Good morning. I have a lot of information to cover in a short period of time, so I would like to ask for you to refrain from asking any questions until after both presentations are given today.
[Overhead: Traditional billing definitions]
I would like to start off with traditional billing definitions, the first of which is gross lines. Most of you in the audience probably know what a gross line is, which is also referred to as a “visual line count”. Every line on the page that has text counts as a “line” and every blank line doesn’t. There are a few variables that affect gross line counts. The first of which are blank lines. Some gross line counts include blank lines and some don’t. The next is margin widths. By increasing or decreasing margins widths, you can change the gross line count. The same goes for font size and style.
The next type of line is called a character line. A character line consists of characters that are added up on the page and then divided by some quantity, usually 65, 55 or 50. There are two variables that affect character line counts. The first is what counts as a character. Is a space a character? How about tabs or carriage returns? The second is do keystrokes to generate formatting count as characters? In other words, when a transcriptionist has to make a word upper case, does the shift key being depressed count as a character?
The last type of line is the “AAMT defined line”. This type of line is now obsolete, although many companies still use it. According to the AAMT, there are no longer endorsing any sort of billing method. The only criteria is that whatever method is used, it must be independently verifiable by both the client and transcriptionist.
The AAMT line is defined as “Any letter, number, symbol, or function key necessary for the final appearance and content of a document.” An AAMT line consists of 65 of these characters. AAMT defined lines have the same problems as character lines in general, but in addition, because the AAMT definition is so vague, many vendors use it to include every single keystroke generated by the transcriptionist, including keystrokes to run macros, run spelling checkers, and open up word processing programs. This leads to deceptively low line rates.
There are a few other billing definitions that are used less commonly than line definitions. The first one is billing by the page. Billing by the page suffers from the same problems as billing by the gross line. Margins and font selections will change the billing count. In addition, a problem arises where one page may have a few lines of text on it while another one could be completely full. This results is a poor correlation between the amount of transcription produced and the amount billed.
The last method is billing by the minute of dictation. Every minute that the author dictates is a billing unit. While in theory this seems like a great idea because a minute is easy to define, there are a couple of problems that result from this. Different dictation systems produce different dictation times for the same dictation. This is because the start and stop timers begin and end in different places on different dictation systems. Lastly, because authors dictate a different speeds, the same amount of dictation can produce very different amounts of transcription.
[Overhead: page 33 from the '97 July-Aug issue of the JAAMT magazine. Can not reproduce the article here because of copyright restrictions. Reproductions are available from the AAMT, 209-551-0883]
I’m sure most of you use some sort of line counting software to generate billing counts. On the overhead, I have a page from a recent issue of the JAAMT magazine comparing line counting programs. The same files were used with different line counting programs. What they found out was that, depending on the line counting software you use, the line totals could vary by as much as ten to fifteen percent. So, I would recommend to everyone in the audience, if you would like to give yourself and immediate raise, make sure you are using the line counting software that generates the highest line counts!
[Overhead: Line rate conversions]
Next, I will go over some line rate conversions that I will be using for my next example. The sheet on the overhead is based on the most common line definitions used in the industry. As you can see, you can convert from a gross line to a 65 character line by multiplying the gross line by 1.44. And if you want to convert from a 65 character line to a gross line, you would divide your 65 character line by .69. If you want to convert from a character line to a character line, you would take the price per character and multiply it by the number of characters in the line.
[Overhead: RFP1 (this is a .gif image file)]
I have on the overhead now an actual example from a vendor’s RFP. This vendor was asked to provide billing charges as gross lines, 55 character lines, by the ASCII text kilobyte, and by the method they most commonly use. As you can see, this vendor charges $.1325 per gross line. They charge $.1350 per 55 character line. Now, if you apply our conversion factors here, you should realize that this rate should be closer to 16 cents per 55 character line. This vendor did not quote a price per kilobyte, but their most commonly used definition is based on the AAMT character line, which they charge $.1395 for. Again if you apply our conversion factor here, this should really be closer to 19 cents per AAMT line.
The client who sent in this RFP also asked that they be provided the actual costs of transcribing some enclosed sample reports. For some reason, this vendor is quoting a different price to transcribe the same report depending on the billing method used. This almost seems to imply that there is some intrinsic overhead to billing by, for instance, a 55 character line, verses a gross line.
[Overhead: RFP2 (this is a .gif image file)]
The second RFP I have just placed on the overhead shows the same things with billing line counts. As you can see, this vendor charges $.145 for a gross line. They did not state a rate for a 55 character line, but did state a rate of $4.61 for an ASCII kilobyte. If you do some calculations here, this equates to about 29 cents a 65 character line which would imply either a mistake or a misunderstanding about what a kilobyte is.
Lastly, the charge .125 per AAMT line. This should be a red flag. A 65 character line, be it AAMT or not, should always be more per line than a gross line. But in this case, it is substantially less, which would lead me to believe that this vendor is manipulating the AAMT line definition to get a deceptively low line rate.
And again, for some reason this vendor is quoting different prices to transcribe the same report depending on the billing method.
Now, with all the problems associated with traditional billing methods, is there any way that is indisputable and easy to understand? There is: it’s called ASCII text.
[Overhead: ASCII text]
For those of you who are not familiar with ASCII text, it is the most simple way of storing text on a computer. ASCII text contains no formatting commands such as bolds or margins. What you type on the keyboard is exactly what you get in the file, so you get a nice one to one correlation between the number of characters, or bytes in the file and the amount that was typed. This is because, with ASCII text files, one character equals one byte.
In the computer world, if you take 1024 characters or bytes, you have a unit called a kilobyte. An interesting thing about a kilobyte is that is contains about one-half to two-thirds of a page of text so you can get a rough feel for the actual amount a report would cost to type.
Almost every program made since the 1970’s can import and export ASCII text. This includes word processing programs, spreadsheets and databases. HL7, which is a way of exchanging information with different computer systems in the health care environment, uses ASCII text as the method of storing transcriptions.
Some of you may have heard of “byte counts” before which is essentially the same system used with ASCII text files. The difference is that most transcription companies that do byte counts do them on word processing files. Word processing files contain lots of extra characters for formatting commands and printer setups that are not contained in ASCII text files.
Because you can’t do as much formatting in ASCII text files, there needs to be a reassessment of what transcription really is. Dictation generates valuable data, not word processing. The primary goal of medical transcription is the accurate capture, and in some cases translation of data. The secondary goal is formatting. With this in mind, I will go over some of the pros and cons of using ASCII text for transcribing.
Billing by the number of kilobytes in an ASCII text file offers an easy method for both clients and transcriptionist to independently verify that they are being billed and paid correctly. This is because any computer system has the native ability to add up the total size of all the files in a particular directory or directories.
The interesting thing is that because less formatting can by done in ASCII text files, transcriptionists spend less time formatting and become more productive.
If transcription is provided as ASCII text, it releases the vendor from having to use a particular word processing program. This means that any word processing program or customized application can be used to produce transcriptions, thereby increasing efficiency.
Lastly, ASCII text is directly compatible with many computer systems and software while word processing files are not.
[Overhead: ASCII report example converted to HTML / ASCII report example as a .txt file]
There are a few cons to using ASCII text for transcribing. The first of which is ASCII text does limit the amount of formatting that can be done in a report. But this may not be as bad as it seems. On the overhead, I have a sample ER report transcribed as ASCII text. As you can see it is perfectly readable. I worked with the client that uses this format and totally redid their report format. The end result is that their physicians find the new report format is actually much more readable than their previous one. At the company I work for, we’ve successfully transferred over 80% of our clients over to ASCII text.
Another problem is educating clients and transcriptionists on ASCII text. But once the understanding is there, it is easy to understand the elegance of using this system.
A few people have brought up to me the problems od “padding” ASCII text files with extra spaces or carriage returns to artificially boost the billing amount. This problem is not unique to billing by the kilobyte. If you bill by either gross or character lines, these will also boost your billing count. If either you or your client are concerned about this, it is very easy to write a simple program that will look for multiple instances of spaces or other characters. This is because working with ASCII text is much easier than a word processing file.
Before I finish, I would like to introduce you to ASMART, The Association for the Sensible Method of Acquiring Rates for Transcription. ASMART’s goal is to promote honesty and educating in transcription service billing, and to do this through extolling the virtues of ASCII text. Right now, ASMART is looking for anyone who is interested in working with ASMART to promote this goals.
Membership in ASMART is free, and contact information is on the overhead. Benefits of membership are twofold: education, and if you are a vendor, you can list yourself in a database of other vendors who are willing to bill by the kilobyte and provide transcription as ASCII text. Clients will be using the database to choose transcription services.
ASMART has also released a free ASCII report printer that makes batch printing ASCII text files much easier. It’s available on the ASMART web site.
I know I’ve covered a lot of information in a short period of time. Your MTIA packets should contain an ASMART white paper for more details. You will also be able to ask questions after the next presentation. Thank you.
