Feature Story

AP vs. CP, scope, RFPs: Portal gets green light—now what?

What to consider about test-order entry

May 2004
Karen Titus

After months of discussion and deliberation, your lab has decided to move forward with a portal.

Now the real work begins.

While there’s nothing simple about taking that first step toward Internet-based order entry and results reporting, the next task—selecting the right system—is no après-ski. In fact, doing it well requires labs to do more than sift through their technical requirements. They need to soak up the details of their business and pinpoint their competitive advantages.

But if you do that well, says Walter Henricks, MD, director of laboratory information services, The Cleveland Clinic Foundation, the payoff will be big.

Dr. Henricks spoke at the Lab InfoTech Summit in early March, and in a followup interview with CAP TODAY he discussed how to ease the pain of selecting lab portal software.

Start by thinking big, he advises. Big picture, that is. "There are some fundamental decisions that will not only guide your process but may be important to what vendor you select," says Dr. Henricks. That means asking basic questions about the scope of the lab and the lab portal, including:

• What types of clients will you serve? Clinical lab, anatomic pathology, or both? Hospitals, physician offices, or other settings?
• How many client sites will you install? In what time frame? Will you be working with new clients, existing clients, or a combination?
• Will you be adding new services, such as demographic data management and point-of-care testing data integration? What about other types of orders, such as radiology and prescriptions?

"Some of this might seem self-evident, but until you start asking these questions, it might not be," says Dr. Henricks.

Clinical and anatomic pathology are fundamentally different when it comes to lab portals, with AP having unique demands. Labs that decide to provide order entry via a portal need a system that will allow the ordering physician to specify the site or organ from which the specimen was taken and to add descriptive information and discussion. The system also needs to accept clinical history and allow users to make multiple entries. "The physician or client might be submitting one biopsy, or six biopsies from a colonoscopy, or eight biopsies from a prostate," he explains. "So there has to be the flexibility to handle that. Those are different considerations from just picking off lab tests from a checklist."

Labs may have different systems for CP and AP, requiring an additional interface between the two—which also affects the scope and cost of the project.

Another difference: Unlike their CP counterparts, interfaces to AP systems typically do not electronically pass orders directly into the LIS. "A lot of AP systems are still paper-based, so you may be looking for the portal to generate a quality paper requisition, perhaps with two-dimensional bar coding that would automate or semiautomate the information entry when the case is accessioned in the laboratory."

Labs occasionally overlook vital details, Dr. Henricks says, especially with AP systems. For example, some labs don’t account for the amount of training needed to bring physician offices on board, especially with new clients. "Current clients at least know a little bit about your processes, versus new clients have to learn a new system and new processes. So it might be good," he suggests, "to start with current clients."

The demands of demographic data management can easily be underestimated. Labs need to consider how demographics—patient name and address, insurance and billing information—are linked between the client and the lab. Does the information need to be re-entered into the LIS? Is there a one-time data dump from the physician office system into the portal? Or does the information travel via a batch-mode transfer or real-time interface? A particular method "may be an expectation of your clients," Dr. Henricks says. "But at the same time that can mean significant overhead and effort for the laboratory."

Labs also need to decide whether they’re going to provide the Internet connection for the client site. What may be attractive for the client may be less so for the lab. Such service is costly, Dr. Henricks says, and "managing that last mile, the technical aspects of getting the physician management system online," takes its toll. "It would be a lot easier to go to clients who already have an existing Web connection and have them log on to your site through that." Labs must also steer clear, he says, of providing Internet connectivity "as an inducement."

Order entry can be complicated, requiring plenty of training. But it may be worth the effort. "Again, it speaks to the issue of scope. Does the lab want to say, Look, we’re just going to give you results? Or does it want to try to institute order entry—which has a lot more payoff."

Consider the pros and cons, says Dr. Henricks, before deciding. When orders are interfaced directly into the LIS, the process is entirely automated for clients and no paper requisitions are required. There’s also less accessioning work in the lab. On the other hand, this approach means labs must deal with pending cases—orders that are placed but never fulfilled, either because the patient was a no-show or because the specimen never arrived at the lab. It’s also more expensive, requires more system maintenance, and is more dependent on connectivity.

When clients enter orders into the Web portal system and print requisitions, all specimens have requisitions; the bar-coded data on the requisitions, in turn, makes for easier accessioning in the lab. This method is less expensive and needs less technical support and maintenance. However, this paper-based system also means more accessioning work when the specimen reaches the lab.

There’s a third option, Dr. Henricks says, in which clients do no order entry, and results are available on the Web. "That’s the easiest for the client, and that’s mostly what they want." It’s also easy on labs, because it requires fewer interfaces and less money and training. But it’s accompanied by a slight disadvantage: Clients don’t get so-called clean claims or clean orders, which automated compliance checks can simplify.

Another challenge will arise if more physician office practices adopt electronic medical records. "I could easily conceive that outreach clients with EMRs will want their lab results interfaced to their physician office EMR. And that will be complicated."

None of this comes cheap. It’s easy, though, to be misled about costs, especially when blinded by attractive initial prices. But be skeptical. "It’s just like anything else in life," says Dr. Henricks. "You see an ad in the paper—you can get this car for $8,999. But if you want four wheels. . . ."

It’s not that vendors have inappropriate practices, he hastens to add. "I’m just saying you have to ask many questions to ensure you understand all of the costs. You have acquisition costs for the software and potentially hardware, and you have recurring costs for maintenance. Depending on the pricing structure, you might also have subscription or transaction costs, especially if the portal vendor is hosting it for you and you’re using the application service provider."

Enter the request for proposal. As the lab digs into the scope of its portal project, the answers to its questions will help frame the RFP.

"The most important aspect of an RFP is it adds structure to your thinking and to the process," Dr. Henricks says. "It also provides the means for documentation and completeness, that all the questions were asked and the issues put on the table."

It will also root out vendor answers that are more echt than aught. "It’s important in an RFP to ask not only whether a feature is present in the system the vendor offers, but whether it’s in its current release, or in beta, or as a future item. Or do they offer it as a custom?" Dr. Henricks says.

Likewise, the RFP responses get vendors on record, and those responses can be included as part of the final contract. "It’s important to let them know upfront that you plan to do that. But it’s a valid practice, absolutely, and most people do it."

But RFPs can also be misleading, he cautions, especially if labs bury their heads in numeric criteria. A traditional RFP scoring method assigns a weighted value to each item based on its importance—five being the most important, for example—and then a score is assigned for each answer. If a vendor answers "yes" to a five-point-weight question, and the "yes" is scored at three (a "no" could be worth zero, and a beta could be worth two), that item will receive 15 points. After all the scores are added up, the vendor with the highest total would appear to be the winner. "But that only looks at one aspect of the vendor—functionality, and maybe technical architecture. But the numerical method may be constraining and misleading. You can get into trouble if you stop thinking and just rely on numbers."

Dr. Henricks, whose lab is in the final stages of selecting a portal, says he finds it more useful to use the RFP to spot red flags. "We look at all the vendors’ answers, we tabulate them, and we look at which functionalities are not available from which vendors—we basically tabulate the non-yes answers. And then we can see right away, if any of those ’no’s’ are deal-breakers, that it’s pointless to continue with certain vendors or systems."

Apart from this type of negative profiling, the RFP can help labs zero in on key features, including duplicate order checking. What if a physician orders a test panel, then separately orders a test that’s part of the panel? "Can the system flag that? You might assume it can if the vendor answers ’yes’ to a question about duplicate order checking. But you need to ask about these types of semiduplicate orders specifically."

Nor should you gloss over results viewing. If your lab plans to use the system for numeric and text results, make sure the system can display both. "Frequently in demos they’ll show you a CBC, which will be a nice, straight column of numbers," Dr. Henricks says. Other tests—susceptibility panels, coagulation testing panels, monoclonal protein evaluations—are a different matter. "Find out how those are handled. How do they look? How are they displayed?" And how flexible are criteria for results inquiry? Can you easily apply filters and inquire by date range, ordering physician, etc.?

Order entry can be another nasty nest. Labs may overlook the capture of additional data for tests such as prenatal screens, cystic fibrosis, and heavy metals, data that may include family history, ethnicity, address, and gestational age. If you’re doing order entry, it has to be entered into the system and then transmitted to the lab. "Can the interface handle it?" Dr. Henricks asks. "What happens to that information? It’s easy to underestimate this. You need a lot of flexibility in a system to handle these kinds of tests." Also find out how easy it is to configure order sets for clients with different test mixes.

Packing manifests—the list of specimens and related information being transmitted to the lab—are another stumbling block. "How easy is it for your lab to decipher what’s on the packing list—what you received, what you didn’t receive? How configurable is the list? How complete is it?"

Vendors’ RFP responses are filled with clues. But the lab has to know how to look for them.

Ideally the RFP is a two-way street. "The more you can provide to the vendor candidates about your site, the better they’ll be able to answer your questions." That could include test volume, the problems you’re looking for the system to solve, the setting it will be deployed in, and who the users will be.

"The more specific your questions, the more specific the answers," says Dr. Henricks. "And if the answer isn’t specific, that tells you something."

At the same time, there’s room for open-ended questions. "For example, ask them, What are your support policies? And just let them answer."

Some questions can be addressed during the vendor demonstration. This is not the time for a dog and pony show. Instead, think of the vendor as a politician who needs to be moved off-message, away from canned remarks. "The most effective demos are the ones where the lab prepares and tells the vendor specifically what they want to see. We found it very useful to provide potential vendors with examples of our current problems or challenges, things we wanted a system to handle."

Also try to assess vendors’ strengths down the road. Ask them about their commitment to research and development. "Some will even share percentages in their budget devoted to that." How many people are devoted to R&D? How many upgrades a year do they do? How many new features have they implemented in the last year? What’s their process for doing so? Do they have a users’ group? What’s their mechanism for taking user feedback? What number of user requests have been put into their software? What are their views on SNOMED and LOINC? What do they think about digital imaging? "All of this is evidence of developmental activity."

Their answers should help steer your lab to a portal that will solve more problems than it creates. And while your work still may not be done, your job could certainly become easier.

Karen Titus is CAP TODAY contributing editor and co-managing editor.