The Association for the Sensible Method of Acquiring Rates for Transcription (ASMART)
We promote:
Introduction
Today, two major problems exist for clinics and hospitals that use an outside transcription service:
• Cutting the cost of transcription.
• Difficult to understand, unverifiable billing methods.
A third problem exists because many transcription service vendors are prevented from improving efficiency because they are tied to specific word processing file formats. ASMART promotes a simple solution for solving all of these problems.
The "voodoo" line count
Most transcription services charge by a unit called a "line". Paying by a "line" was introduced when transcription was first produced on typewriters. At that time it was a logical way to bill because you could count the lines by hand (after all, back then there was no other way to count them). This sort of line is commonly referred to as a "gross" line. There was no standard for how you were supposed to count lines. Should you include blank lines? How wide should the margins be? What font and font size should be used? Even if you use courier 12 point on all the reports you are comparing, the size of this font will vary depending on the word processor and computer system, and even the printer you use. The selection of margin size and font is critical because changing them would result in a drastic change in the total number of lines counted. So, from the beginning of transcription history, you could not directly compare vendor line pricing to judge if company "x" was more cost competitive than company "y".
Then along came computers. Computers offered automatic line counting through software that counted characters in word processing files. So an alternate line counting method arose called a "character line". You would calculate the total number of characters in a report and then divide by a certain figure, say 65, to come up with a total number of lines in the report.
This is not as simple as it may seem. What characters do you count? Which ones don't you count? Do you count a keystroke to make a bold or underline as a character? Some services would define their line as consisting of 65 characters, some used 45 and others 55 or some other number. Again, there was no standard with which to directly compare different vendors against each other.
Adding to this complexity, character lines can be counted differently. Some services count invisible word processing characters while others count spaces, and some don’t. Some charge for bolds and underlines while again, some don’t. The end result is that a transcribed report billed by the gross line can sometimes cost 40% more than the same report billed by a 65 character line. And a 65 character line that counts spaces, bolds, etc. can increase the line count 10 to 20% more than a 65 character line that doesn’t include these characters. And an increased line count increases the cost of the report.
Simply put, there is no such thing as a "standard line". But yet clients often purchase transcribing services with the assumption "a line is a line". Here’s an analogy: let’s say you run a zoo and need to buy shoes for all of your animals. But instead of buying shoes by the pair, you buy them by animal headcount. For you, this is a big problem because you could be buying too many shoes; after all, some animals have two feet while others have four. Unfortunately, this is the way "lines" are bought.
There have been charges in the industry that certain, less than ethical transcription service owners play line count "voodoo" on clients by redefining lines on the fly to make their service "seem" cheaper than their competition. There are documented cases of hospitals and clinics switching services under the guise of a lower rate per line and actually paying more for the new service. Services can do this because—and this is very important—clients often do not have any way of independently verifying how they are charged by the service.
There are software products on the market that "count" lines, but their line definitions are "canned" and may not exactly match how the client is getting billed by their service. A client could count lines by hand, but this can be incredibly time consuming and is almost never done. Some clients get around this problem by requiring their vendor to count using a third party line counter. However, this just makes the line count software vendor an "unofficial" standards body. What happens if the software vendor goes out of business or releases software with bugs? Does it make sense for a client to base hundreds of thousands of dollars on such a dubious "standard"?
Cost cutting is the number one priority of the health care industry, but with such a bizarre way of billing, controlling transcription service cost is difficult at best. After all, you can buy everything from syringes to bandages to electricity by an easily definable quantity. Is it even possible to find an easy, simple way to bill for transcribing services that allows clients to compare one vendor to another?
The standard promoted by ASMART
ASMART was started as an independent organization to offer a common billing definition that all transcription services could use and all clients would request. Free membership in ASMART is open to both transcription service owners and their clients because by definition ASMART is biased neither towards the vendor nor the client. ASMART offers a way for clients to know what transcription services offer the billing method proposed by ASMART as well as an open education forum for all members.
Healthcare organizations are moving towards the "electronic patient record". With this comes the need to integrate transcribed patient reports into a database on a computer system. With this in mind, it makes sense to define a standard that is compatible with information technology. The standard proposed by ASMART is based on an ASCII text file. Here's an overview for those of you who are unfamiliar with what an ASCII text file is:
All computers can generate up to 256 characters. 128 of these characters were defined as "standard" characters known as the American Standard Code (for) Information Interchange. So when you say an ASCII text file, you are saying that it’s a file that is composed from those 128 ASCII characters. And all computers currently in use on the face of the planet use ASCII characters. The 128 ASCII characters mainly consist of exactly the same characters that can be typed on a computer keyboard. For instance, if I type an "a", it’s also known as ASCII character number 97. An uppercase "A" would be known as ASCII character number 65.
You have seen ASCII text files before if you've ever read a "readme" file that commonly comes with computer software after it is installed on your computer. Internet e-mail, as well as most other E-mail is also a common form of an ASCII text file.
An ASCII text file contains exactly what is typed by a transcriptionist. No special function keys. No more, no less. There are no formatting codes or commands inserted by the word processor. And all computers come with a built-in character counter when used in the right context. If you’ve ever seen a listing that tells you that there’s so many bytes in a file, what this is also telling you is that the file contains the exact same number of characters. The important thing to remember is that a byte is the same as a character.
In fact, most of you probably have a chart of the ASCII characters on your bookshelf. The WordPerfect 5.1 manual in Appendix A has a "ASCII Conversion Chart". From that chart, here is a listing of the characters defined by the ASCII standard that would be in an ASCII text file. Remember, the only characters that can get into an ASCII text file MUST be typed from the keyboard. In other words, if you do not see the key on the computer keyboard, it won’t be in an ASCII text file:
These make up every single character that would ever be in an ASCII text file.
For example, if a hospital or clinic was using this kind of billing system, their vendor would send reports as ASCII text files. The client would immediately be able to verify the number of ASCII characters the vendor should be charging for by pulling up a DOS command prompt, going to the directory where the files are and typing the command "dir" to get a directory listing. At the end of the directory listing, they would see a total of all bytes (or characters) in all of the files. And if you have thousands of files in that same directory, typing the "dir" command will automatically total up every single file for them in a grand summary of the total amount of bytes or characters in the file.
In the computer industry, a byte is often much too small of a unit to use. Instead, you may have heard a term called a "K". Computer "geeks" will often talk this way: "Hey, the program I just downloaded from the Internet is only 10K". In computerese, a "K" is exactly equal to 1024 (i.e., not 1000) bytes because that's how your computer defines it*. A 10K (also known as a 10 KiloByte) file consists of 10,240 bytes or characters. Referring to characters in units of 1024 is very useful for when your computer tells you that you have, for instance, a 5K, 10K, 18K etc. file.
1K is a magic number. It happens to be coincidental, but an ASCII text file that is exactly 1K (1024 characters) in size is almost exactly equal to the average sized, single page report used in the medical industry. By comparing how much a vendor would charge you for 1024 characters (or 1K), a client could directly compare this report cost against another vendor who's billing on the same standard. With some simple math, the client would be able to find out how much a particular transcribing service would cost in a year if the total number of pages of reports are known for a year's period. If all transcription services were to bill by the standard proposed by ASMART, comparing vendor "x" against vendor "y" would be very simple.
You may be thinking at this point that this sounds like a "byte count" that some services charge by. While the concept in principle is the same, most services who charge by a "byte count" do a count on a word processing file (like WordPerfect). From the client’s perspective, being billed by a "byte count" for a word processing file is a very bad deal. Why? A word processing file contains not only the text the transcriptionist typed, but also formatting characters along with characters that control how the file is printed. These non-text characters can easily bloat the file to over twice of what the raw text would have been. The important thing to remember about an ASCII text file is that it does not contain formatting or printing codes. So the client does not pay for them.
In summary, clients would be billed by the number of characters the computer says is in an ASCII text file. This method is indisputable, does not require third party software, and allows a client to make sure that their chosen transcription service vendor is honest in their billing amounts. In fact, if you were to ask your computer people what’s the most logical way bill for transcriptions, they would also say by the number of characters or bytes in an ASCII text file.
An ASCII text file gives both a client and vendor a simpler, less costly solution. You can not do certain formatting in a text file such as indenting, bolds, underlines, etc. But why would a client want to pay for all of those extra keystrokes to make a report have extra formatting? A simple way to summarize formatting is this: is it worth it to an organization to pay 10% extra on a report so that it will have a few bolds and underlines? To put it in monetary terms, if an organization is billed $250,000 per year, they are paying $25,000 a year for bolds, underlines, indents, etc. That’s a lot to pay for something that does not add to the actual patient documentation in the report!
ASMART's position is that dictation generates valuable data, not word processing. The end goal of word processing is the beauty of the report and the eloquence of the writing. The goal of data entry is to accurately capture raw information in an organized way--which fits medical transcription much better. Data entry is not overly concerned with formatting because it is simply not as important as capturing the data. A good example is to consider a situation where your organization is in legal litigation. Would a judge in a court of law be more concerned with the data or the format of a transcribed report?
An important point to make here is that you can have perfectly acceptable formatting with an ASCII text file to make the report readable. In reality, superfluous formatting makes the transcriptionist a desktop publisher—an expensive luxury. A patient visit is no different than other quantifiable data entered by people into a computer system. Almost every industry in the US that enters data into a computer requires their people enter information directly into a database on the computer. Database programs typically do not have text formatting commands. Why? Because you don’t need them for accurate documentation.
Another benefit an ASCII text file gives you is the ability to directly import your patient documentation into a database to create the "electronic patient report". As mentioned before, most of the new systems on the market do not directly accept WordPerfect 5.1 files. A system like MediTech will not directly import any word processing file formats. But all database systems, regardless of manufacturer will import ASCII text files. A miracle? No, ASCII text is the lingua franca of the computer world. That’s how computers are designed to talk to each other. If you can get your patient report files as ASCII text, you’re already one step ahead of the game in implementing the electronic patient record.
Lastly, in providing transcriptions as ASCII text files, a vendor would be free to choose either the word processing or data entry tool of choice. This would free the vendor to implement productivity enhancements, or even to design a transcription system that would accommodate the fastest, most accurate data entry possible. Being tied to a word processing file format means that the possibilities for productivity enhancements and data storage are severely limited.
Why word processing file formats waste time and money
If you go into a health care organization, you would find that they are very reticent to change their report formats. When asked why, the response is usually, "I’m not sure why our reports should look that way, it’s just the way it’s always been." Consider for a moment that maybe the report format is the biggest obstacle to reducing overall transcription cost.
Research reveals that report formats have evolved from before the days of computers, when all transcribing was done on typewriters. When computers entered the transcribing scene, the same report formats were generally followed, with a few additions such as indenting, bolds, underlines, etc. A gradual pattern started emerging: more characters were being typed to create the same report. Typically, no one has reviewed report formats with the idea of 1.) reducing the number of keystrokes typed by the transcriptionist and 2.) improving the layout for better readability and documentation.
Most report formats are a combination of what the typewriter could do and what the computer can do. Indeed, most client report formats are done in the courier font. This is the font typewriters use: in the typographic world this is called a monospaced font. An important point about monospaced fonts is that they are harder to read. That’s why you don’t see books printed in the courier font because your eyes would "bug out" after a short time. But yet we are often told that report formats are the way they are for "readability". Maybe one should ask if the goal is to produce transcribed reports for readability alone? Obviously, the primary goal is accurate, portable, patient documentation first, cost second and format last. The format of the report is important to make sure it is readable, but in the order of priority, most people would agree it is not as important as accuracy, portability and cost. Simply put, is extravagant formatting worth the extra money? In an environment as cost conscious as the health care industry, fancy formatting flies in the face of reason.
Report formats are often directly tied to a word processor file format, and often transcribing services are required by a client to provide transcription in a particular word processing file format (typically WordPerfect 5.1 for DOS). This limits the transcription service provider because they can not use state of the art technology to improve efficiency which would result in lower costs to the client.
The rest of the business world has moved to a Windows centric world. Yet the transcription industry is one of the last in the US still based on an obsolete word processor. If a service was free to choose their word processor or data entry system of choice, efficiency would go up and cost would go down.
As we move to the age of the computerized patient report, most health information systems are not directly compatible with the WordPerfect 5.1 for DOS file format. And many will not import any sort of word processing file format, period (consider MediTech for example). You may wonder why not take word processing files and export them to ASCII text? The problem is that during exporting, files often become jumbled are incomprehensible because the formatting applied in the word processing program does not translate to ASCII text (this would not be a problem if your transcriptionist formats with the knowledge she will be saving the report as ASCII text). In addition, the sheer number of files that would need to be converted would require an automated system--and such a system would not be able to catch and accurately correct formatting errors. Lastly, automated systems for converting word processing files to the raw ASCII text proprietary database systems need can cost thousands of dollars.
ASMART services
ASMART exists for several reasons. The primary one is as an education body to disseminate information on improving the state of the transcription industry. Additionally, for clients looking for transcription services we offer a directory of vendors who bill by the methods promoted by ASMART.
Summary
The ASMART organization firmly believes that the solutions provided are what the health care industry is asking for: lower costs and increased efficiency. If you are a health care organization or a transcription service, membership in ASMART is free. For more information, please e-mail us at ASMART@transcription.com or write ASMART, 7511 W. Arrowhead Ave., Ste. H., Kennewick, WA 99336.
*Warning! Computer geek talk! In the computer world, there are 1024 bytes in a kilobyte because 210 = 1024. On the computer all information is processed in a "binary" fashion (i.e., there are two possible states for information to exist in). Binary numbers are also known as base 2 (our normal numbering system is base 10). Moving the radix point in base 2(equivalent to a decimal point in base 10) is more complex if you tie it to 100010 because 100010 is not equivalent to an integer power of 2.
Copyright 1997 by ASMART