CEO SUMMARY: During 1999, many factors pointed to the speedy introduction of Web-based lab test ordering between physicians’ offices and their laboratory providers. Several credible players, like Healtheon/ WebMD (now WebMD) and Advanced Health Technologies, held numerous contracts to implement Web-based lab test ordering and results reporting. But Web-based lab test ordering never gained traction. Most first generation software products performed poorly and failed to meet expectations, both of labs and their office-based physician clients.
PART TWO OF A SERIES
EDITOR’S NOTE: The career of Cory Fishkin, President of Mostly Medical, Inc., has been focused on developing innovative informatics solutions for labs. During the past ten years, he’s worked at such companies as Bukstel and Halfpenny (originator of Dr. Chart), Reuters Health, and Abaton.com (before and after it was acquired by McKesson Corporation). He is considered to have as much first-hand experience in implementing Web-enabled lab test ordering and results reporting as anyone in the lab industry today.
WEB-ENABLED LABORATORY TEST ordering is still in its infancy. Presently only a handful of laboratories have implemented this feature, so there remains much mystery and misinformation about using the Internet for lab test ordering.
In recent years, I’ve been involved in refining the lab test ordering and reporting system of Abaton.com and helping early-adopter laboratories introduce these services to their office-based physician clients.
In responding to lab RFPs and watching competitors, I’ve had a unique view of the good, the bad, and the ugly of Web-browser-based systems for lab test ordering and results reporting. Having earlier shared my insights about selecting test results reporting systems (See TDR, July 23, 2001.) I would now like to do the same with lab test ordering.
Reporting Results Is Easier
Most lab administrators and pathologists know lab test reporting is a much easier task to accomplish than lab test reporting, for a simple reason. In reporting results, the lab starts with all the information it needs to provide to its physician-clients. Better yet, the IT staff usually has experience reporting HL-7 data to clinical systems.
This is not the case with lab test ordering, where the lab literally must rely on the physician’s office to provide all the information necessary to properly accession the specimen, perform the test, report the results, and successfully bill. As well, the IT staff often has little experience with HL-7 order messages. It is important to remember this fundamental difference as we discuss the challenges of designing an effective Web browser-based test ordering system. The laboratory must rely upon the physician’s office to provide it with full and complete information to properly process the lab test requisition.
Incomplete, Inaccurate, Illegible
Paper requisitions illustrate the challenge. When left to the physician and his staff to “fill in the blanks,”? many paper requisitions arrive in the lab with incomplete, inaccurate, or illegible information. Here is the first slippery slope which trips up many vendors as they build a lab test ordering system.
A good order entry (OE) system is designed to minimize the effort required by doctors and their staffs to complete the test requisition. The best tools to accomplish this are interfaces with the practice management software (PMS), autofill’s, and easy-to-access test dictionaries.
The next slippery slope for vendors is the complexity of an individual laboratory’s “testing rules.”? These govern how the test requisition is completed, which lab is to perform the test, how results are generated and reported, and how the lab bills for reimbursement.
Vendors are challenged to: 1) capture each lab’s individual range of procedural rules within the software system; and 2) design a system that prompts and guides the physician to complete the test requisition accurately, without becoming burden- some in the number of screens, pull-down menus, and tables the physician or staff must negotiate as part of the process.
What makes this even more difficult for vendors is the fact that existing browser-based software technology cannot perform tasks in as simple a manner as the DOS-based and client server systems which have performed so well during the past ten years.
I can best illustrate this concept by pointing out that banks, airlines, hotels, and most retail merchant accounting systems continue to use character-based systems, which rely on “tab” and “enter” keys to move through the screens.
Browser technology is built upon graphical user interfaces (GUI) and rely upon “the mouse,” “drop down menus,” and “clicks”? to move through the screens. As it turned out, the earliest OE systems required the operator to perform too many of these steps to generate a completed lab test requisition. Newer browser-based OE systems try to emulate aspects of the “tab” and “enter” type of user interface to streamline the process.
Surprised By Complexity
The next surprise to vendors was the complexity of the “data model.” This is a term used by software designers to describe the number of elements in a data base and how they must be linked. It is not unusual for the typical laboratory to offer 1,000 to 2,000 tests, some with multiple order entry requirements. To this data base must be added sizeable numbers of patients, physician accounts, payers and managed care contracts. Linking these data sets is an exhausting and never-ending task.
Taken collectively, these were the factors that made it difficult for the first generation of OE systems to perform acceptably. Early adopter laboratories were surprised by the lack of performance. Compared to existing character-based OE systems which typically refreshed a screen in three to four seconds or less, these first browser-based OE systems often required up to 20 seconds or more to refresh a screen.
Not surprisingly, physicians and their office staff did not embrace these browser-based lab test ordering systems. Compared to the existing DOS and character-based systems already in use in their offices, they viewed browser-based systems as a step backwards.
No Widespread Broadband
At this point, I think it is fair to note that the earliest OE vendors believed what the telecom companies were saying. From the mid-1990s forward, a number of credible companies promised that broadband Internet access would be widespread among business and consumers. DSL, cable modems, and other technologies would enable browser-based systems to use the Internet to speed up all sorts of commercial transactions. Pioneering lab OE companies counted on this actually occurring.
Today, in 2001, we know this didn’t happen except in certain metropolitan areas. Most consumers and most physicians’ offices still do not have high-speed Internet access. The recent financial problems of telecom and broadband companies amply demonstrate that predictions of widespread broadband access were overly-optimistic.
Since the earliest browser-based laboratory OE systems were designed with the expectation that users would have broadband Internet access, it should surprise no one that so many performed poorly when used on a dial- up Internet connection.
New Generation OE Systems
Collectively, these factors provide a good basis for understanding how we arrived at the current state for lab order entry systems. Today a lab can consider a variety of products, many of which are second or third generation. The best of these products reflect the experience of the past three years.
With that in mind, I believe a laboratory should ask questions about these 11 important functions when considering the purchase of such systems:
1) How easily does the OE system interface with physician’s practice management systems (PMS)? Essentially, the interface allows the OE system to pull patient demographics and billing information directly from the PMS. This is crucial to the success of any hospital laboratory outreach program because physicians and their staff, when filling out the lab req, want to avoid entering duplicate data of information which they have already entered into their PMS.
Labs should realize that interfaces between browser-based OE systems and the doctors’ PMS are difficult because of the differences in technology and platforms. For the interface to work, the PMS must export data to the ASP data center. Alternatively, a software module that communicates with the PMS can be installed on the browser’s PC. However, this solution defeats the goal of true thin client architecture.
It’s also important to know that busy physicians’ offices are already savvy on this topic. They know these interfaces exist. That’s because the national labs have done a good job of creating interfaces with most of the major PMS products.
2) How does the OE system interface with the lab’s LIS? In the commercial lab setting, this is relatively easy, because one IT system generally manages testing information and financial and billing information.
This differs from hospital settings, where a patient registration module exists independent of the LIS. To function in this setting the browser-based OE requires two interfaces; one to link the OE to the patient registration system and one to link with the LIS. Moreover, some hospitals have a method to check and insure correct identification of the patient using an MPI (Master Patient Index). This feature can often complicate the interface.
One interesting workaround to resolve the interface problem involves using PDF 417 bar codes. PDF 417 is a two-dimensional bar code easily capable of encoding 100% of the data on the test requisition. When the physician’s office completes the requisition, the OE system generates a bar code that goes on the requisition. When the lab receives the paper requisition, it scans the bar code and the data is automatically read into the LIS.
This is quite efficient and can eliminate the need for an interface between the browser-based OE and the LIS. Quest Diagnostics Incorporated uses this approach in several of its labs. Sunrise Medical Laboratories, in Hauppauge, New York, uses PDF 417 labels on all its test reqs as the primary method to get information into its Antrim LIS system.
3) When an OE vendor contracts with a laboratory, how does the vendor incorporate the lab’s test catalog and rules into its OE system? Effectively, this is the task of converting the OE system into a customized product for that laboratory customer. It’s a substantial amount of work in its own right.
Many labs do not already have this information in electronic format. For those that do, there are often no effective tools that the lab can use to export data to the vendor or for the vendor to import data from the lab.
Not surprisingly, setting up the lab’s rules into the OE system is frequently a difficult and trying process for both the lab customer and the OE vendor. Typically, it can take 60 days to convert the data necessary to implement lab test reporting and between 90 to 270 days to convert data for browser-based test ordering.
Newer vendors to the OE market spend less time on managing this issue initially, because they have fewer customers. Vendors typically improve this function in their later product releases.
Once a lab’s OE system is implemented, there is the need to update changes in rules and the lab test directory. You will want to ask whether the vendor requires your lab to transmit a file with updates and rules changes, which the vendor will then update. More preferable is the capability of the OE product to allow the lab to do its own updates and not require the vendor to get involved.
4) How easy is it for the doctor to order a test and complete the requisition? Earlier I described the problem of performance, as measured by lengthy screen refreshes and having too many mouse clicks and drop down menus. I always try to design an OE system with as few screens as possible to complete the test requisition.
There’s a secret that will help you evaluate this aspect of “ease of use.” The secret involves how often the enter key must be hit. In browser-based systems, this triggers a cycle where data is sent to the remote host, processed, sent back and the screen is refreshed with the new information. This is a major source of time delays and causes much frustration to a doctor and his staff.
My approach is generally to combine screens wherever possible. For example, does the OE system require separate screens for information about the patient, the payer, the guarantor, and for test order and test diagnoses? Each individual screen adds to the total time for completing a requisition because of the time to transmit and refresh. Combining screens is an effective way to help resolve this issue.
5) Does the OE system prevent the user from skipping “required”? data items? Certainly the laboratory wants a complete test requisition, along with the correct ICD-9 code and payer information. But preventing the user from skipping a blank field can frustrate the physician and his staff. I prefer the approach where the system gives a warning that the information is required, and allows the user to override the warning and continue. After all, we don’t know the clinical situation. This arrangement allows the user to request a test with the understanding that the lab is going to call and request the missing information.
6) Can the OE system track managed care contracts? Because of exclusive laboratory provider contracts with certain payers, it is an advantage if the OE system can alert the user that a patient has a specific managed care plan. This allows the physician’s office to direct the specimen to the correct lab and cuts down delays in getting the specimen to the right lab as well as downstream problems in billing for those tests.
7) Can the OE system respond to special information requirements? There are a variety of tests, particularly in cytology and pathology, which require detailed and specific information to perform the test properly. The OE system must be able to recognize these special tests and properly gather this information at the time the requisition is prepared in the physician’s office. The best OE systems do this very well, but be forewarned that not all products perform strongly in this regard.
8) Can the OE system identify duplicate tests which are being ordered? Here’s an overlooked benefit to the users of OE systems. Simply put, the OE should have the ability to check whether a test has already been ordered within a panel. It should also alert the user that the test was ordered within the past 30 days, perhaps by another physician within the group.
This feature is a way for the laboratory to add value to its physician-clients. We frequently saw situations where large groups and IPAs (independent physician association) were “at risk”? with a capitated contract. We learned that much duplicate testing occurred because, when the doctor looked at the chart, an earlier test result had not yet been posted. We added this feature to the OE functions at Abaton.com because it had real and positive impact. Our clients told us their internal studies indicated that as much as 10% of all lab tests are ordered only because an earlier test result was not in the chart at the time a patient was being seen by the doctor!
9) Does the OE system require too many look-ups to enter the right tests and diagnosis codes? Can the OE system strike the right balance between efficiently guiding a novice user while at the same time allowing the “power-user,” who has the same daily ordering patterns, to speed through the screens? My recommendation is that the OE system should allow several test codes, separated by a space or comma, to go in one field and be processed with one stroke of the enter key, like the entry screens of many LIS systems. The same should be true of ICD-9 codes. These processes should not require a drop-down menu for the power-user.
10) Can the OE system easily add and delete tests as well as reprint an order? This is a customer-friendly feature. Some OE systems allow the physician to add or delete tests to an order and reprint it. Other systems require a new requisition to be prepared from scratch. At Abaton.com, we actually enhanced the product so a customer could add tests to an already-transmitted requisition. We accomplished this by allowing the user to review the existing order and “add-on”? a test without having to create a new requisition from scratch.
11) Can the OE system track tests from order to reported results? I consider this a critically important function for a good OE system. It should allow the ordering party to track a lab test order from origination to reported result.
This is important because most physicians’ offices already keep a hand log or a copy of the daily lab orders. The staff checks off items on this log as test results are received. When an OE system has tracking capability, the office staff is thrilled with the opportunity to scrap the hand log and track test orders electronically. When this feature was added in later releases of Abaton.com, it proved quite popular with clients.
Based on work with health system laboratories, hospital-based labs, and independent commercial laboratories, my belief has always been that both laboratories and physician office clients share a mutual self-interest in the success of browser-based order entry. The potential benefits to both parties are substantial.
The first part of this briefing covered some of the challenges and difficulties encountered by the pioneering companies that entered the browser-based OE lab market three and four years ago. It is important to understand why browser-based OE systems face different technical challenges than existing character-based systems. With each product release, pioneering vendors are implementing solutions to these problems.
That is why I believe the current “best-of-class” systems can deliver the type of performance expected by laboratory purchasers and physicians’ office users. As the market moves forward, ongoing advances in technology and bandwidth should continue to improve the performance and capability of these products.
Cory’s “Cool Features” Are Suggested For Browser-based Lab Test Ordering
YOU CAN CALL THESE “Cory’s Cool Features.” What follows are several features and capabilities that add value, but are not commonly found in all browser-based order entry (OE) systems.
•Standing Orders: Can the OE handle standing orders? For example, if the patient is to have a hemoglobin A1c test monthly, can the OE track this? One method is to allow the user to create 12 duplicate requisitions on the patient’s first visit. The unused reqs remained stored in the system and are not assigned a number and sent to the lab until the appropriate month. This type of feature should help with patient compliance issues related to standing orders for lab testing.
•Patient Service Center Support: Can the system be used within the patient service center (PSC) to allow test orders for multiple accounts. This has to do with ordering hierarchy. Many OEs are restricted to a two-level hierarchy; which is the group practice or the “account,”? and which doctor. The system must be capable of a three-level hierarchy, because the PSC must deal with account, then doctor, then patient. Another PSC capability that is useful is checking patient eligibility at the front end.
•Supply Ordering: Is the OE system capable of transmitting orders for supplies from lab clients? Increasingly, this is a popular feature. Some vendors, such as Labtest.com and Labportal.com support this function. The Careevolve.com system also supports a full physician office supply module, not just lab supplies.
•Accounts Receivable Support: Some labs want the capability of reviewing a patient’s financial record at the patient service center. If a balance is owed, this feature allows a lab to trigger some type of collection activity in response to the patient’s current visits to the PSC.