Home > Informatics > Turf Wars: Addressing Demands for Broader Informatics Functionality

Turf Wars: Addressing Demands for Broader Informatics Functionality

It’s decision time — both on the slopes and in the boardroom

Randy C. Hice

It’s been more than six months since my last surgery to repair athletic injuries, and I seem to miss the emergency room. So, I’m headed out the door with my nine- and 11-year-old sons to snowboard. Nothing like locking both feet onto an immoveable board, and throwing a 50+ body onto the earth with teeth-shattering force to elicit unnatural crunching noises. To paraphrase Robert Duvall in Apocalypse Now: “I like the smell of sevoflurane in the morning, it smells like…excitement.”

So, here we are in hard times. Jobless rates are up, spending is down, credit is tight, even the Saudis are feeling the pinch as we use less gas. Venerable Toyota, long accustomed to bathing in the gold from the high demand for their cars, is suffering.

Slope economics
But pity the residents of Aspen, CO, long the enclave for the “stinking rich.” How rich is stinking rich you ask? Well, there are two common jokes making the rounds in Aspen:
• In Aspen, the billionaires are pushing out the millionaires.
• That has since been updated to: What do you call a millionaire in Aspen? Homeless.

Of course, few Denverites bother with Aspen, and that’s part of their problem. There are at least a couple of reasons why Denverites shun Aspen. First, the apoplectic pricing of lodging…the best available rate at the Hotel Jerome I could find was $1,325.00 per night for a normal “junior suite king”, and the “one bedroom suite” commands a brisk $1,725.00 per night. For that kind of money, I expect a hot oil massage each night from Lindsey Vonn, or maybe Billy Kidd…okay, I’d prefer Lindsey if she’s off the World Cup circuit yet.

Second, the distance is a huge factor. Few Denverites would bother flying into Aspen where the skiing is no better, perhaps worse, than at Breckenridge, Keystone, Winter Park and Copper Mountain, all within 1:45. And Vail, arguably one of the top five or so resorts in the world, is only 2:15 from Denver. But, in the winter time, there’s only one route open from Denver, and that requires a drive way past Vail to Glenwood Springs, about three hours from Denver, then a trek south along Colorado highway 82 for at least another hour or more. So, do the math: great skiing 1:45 away, or travel four-plus hours?

Next, there are season passes. Two ski conglomerates compete in Colorado: Intrawest and Vail Resorts. Season passes for Intrawest include access to Winter Park/Mary Jane, Copper Mountain and Steamboat. Although, to be honest, at a three-hour drive, Steamboat is a pretty stiff drive for local Denverites. Vail Resorts includes Vail, Keystone, Breckenridge, Beaver Creek and Arapahoe Basin. Either way, season pass holders usually put in at least 20 to 30 days of skiing a season. Amortizing the cost of the pass, that might work out to $15 to $20 per day. Compare that to the daily lift ticket prices of nearly $100 per day at Vail and Aspen, and you can see why we locals go the season pass route. Ski tourists are puzzled over all the people standing in line seemingly without passes of any sort. That’s because Vail Resorts (with whom I have my season pass), uses RFID technology. Now, the pass can be inside your coat and read by the portable scanners, but for the ski tourists, they must have them out with bar code available.

People fly thousands of miles to ski in Colorado, and are stuck with lift and lodging (and maybe airfare/transfer) packages that roll all the costs together. These ski tourists are the lifeblood of the resorts. Sure, there is the volume of skiers from Denver, but locals have the system down to a science. For example, Denverites, whenever possible try to ski during the week, when lift lines are pretty much nonexistent.

In some of the counties near the resorts, Summit and Eagle, kids go to school longer days Monday through Thursday to get Fridays off. How great is that? Want to take it a step farther? Every school kid in Colorado gets three free passes to nearly every resort in the state in the fifth grade. That’s right…free passes. Hell, even sixth graders are offered the same deal for obscenely low prices.

So, few Denverites pay to stay up in the mountains if they can commute. Get in the car Saturday before 7 AM, on the slopes about when the lifts open, maybe a half hour later. Ski until maybe 3 PM, and get in the car to avoid the traffic jam down the mountain late in the day. Repeat on Sunday. Even when gas was $3 a gallon, most cars can do the round trip on half a tank or less.

Of course, driving on snow-covered, serpentine roads with cars whistling along at 80 MPH on some stretches is not for the faint-hearted. Each week, some overly aggressive driver sails over the guard rail, sending a few long horned sheep scurrying for cover, spurring the rescue and recovery squads into a routine rappelling exercise in a race to get to the victims before the coyotes and the crows pick them clean. Most accidents happen at the end of the day when tired skiers/snowboarders, often marinated in beer and wine, wind their way down to Denver from the Eisenhower Tunnel that burrows beneath the Continental Divide 11,000 feet in the sky. It’s usually a slow, nerve testing crawl up to the mouth of the tunnel at the end of the day. After 1.6 miles of being forced into staying in one lane, the tunnel suddenly opens into several lanes, leading downhill now, and cars punch the gas like it was the green flag at the Daytona 500.

The ski tourists? Well, they pay dearly for staying in close to the slopes. You think oceanfront property is expensive? How about a luxury condo at Vail for $10,000,000? Maybe you would like that nice crackling fire in a rough hewn log home near the slopes? Better plan on $15,000,000 and up…way up. Even the Vail Lodge commands $800 a night, it’s not the Hotel Jerome, but prices are still as steep as the Vail summit.

So, rentals for ski tourists aren’t cheap. Even though a great many condo owners rent their properties during the season, ski condos are not great revenue producers for the owners, but are a great deal for the resorts who charge a fee to rent them out and manage them, but the owners are saddled with the taxes and stuck with the units when no one is renting…which is most of the non-ski months of the year. But the ski tourists pay through the nose to rent these properties, and they must add lift tickets and parking.

Food? The slope side restaurants are packed with coolers, backpacks, and maybe just bags of food in the snow outside. Locals carry in all sorts of food. I saw people with plug-in hot water pots who were making ramen at their tables. So, the resorts don’t make a fortune off the locals in terms of food either. While the resorts must cater to the sheer volume of local skiers, the money is made off the ski tourism industry and, in these hard economic times, tourism is down. So, skiers suffer like the rest of the world, if you accept the frame of reference.

Today’s world of informatics
Economics affects the mindset of large-scale corporations looking to build or refine their informatics infrastructure. One phenomenon we are seeing follows along the chicken-or-the-egg school of thought. Should a company buy multiple applications to address different, although related needs, or should they try to influence the market so that vendors roll a broader suite of functionality into their products? The answer seems to be the latter, and the informatics vendors are responding.

Once upon a time, commercial LIMS products did little more than sample tracking, maybe some bar code label generation, and some even sported instrument interfacing. The market demanded the introduction of lot tracking and stability scheduling. When vendors started to include this in their products, the standalone stability vendors started to drop off the map.

The early 2000s saw the introduction of clinical studies and specimen management functionality, and now the vendors of former hospital level clinical systems are feeling some pain, as are the vendors of specimen storage programs. The big boys in the clinical trials market are not looking back (yet) at the conventional LIMS vendors to supplant them in the clinical trials data crunching realm, but certain chunks of their turf are being slowly consumed.

So, here we are with Web-based LIMS, and now customers are demanding the inclusion of scientific document management system (SDMS) functionality in their LIMS. It is, after all, a logical need to be able to tap disparate data sources: systems and instruments, and process the information cleanly into LIMS.

Now, a few forward-thinking vendors are after the elusive electronic notebook sector. Of course, there is some debate over what the term “electronic notebook” even means. There is a line in the movie Urban Cowboy whereby Debra Winger’s character, Sissy, asks John Travolta’s character, Bud, “Are you a real cowboy?” Bud replies, “It all depends on what you think a real cowboy is.” So it goes with electronic notebooks. Some entrepreneurs have made a living for years charging companies to help develop specifications as to what an electronic notebook should be, and then selling the specifications to vendors to cobble the software together. It’s great work if you can get it.

ELN vs. LIMS
So, is an electronic notebook an area whereby researchers deposit various documents, notes and research to be able to pull it together in a cohesive fashion? Or, is an electronic notebook a means of ensuring compliance to a specific SOP…sometimes called method execution? Well, if you troll the Internet, you get at least those two definitions, and likely several more broad categories.

As corporations start to look for convergence of applications into a single, unified platform, you are already starting to see some electronic notebook functionality being integrated into LIMS platforms. What makes the most sense at this point in the evolutionary continuum is to start from the sample centric, QA/QC side of the curve, and that means SOP management, or the aforementioned method execution. By integrating method execution functionality directly into the LIMS platform, the need to purchase external method execution programs often becomes more of a response to a marketing message than a technological matching of a solution to a need. Keep in mind that method execution is actually a very structured way of moving an analyst through a prescribed SOP, line by line, and allowing all pertinent data to be obtained from instrument interfaces, manual entry, or tapping into other systems.

Indeed, interesting times are already upon us, and lines seem to have been drawn in the sand between the LIMS vendors who are meeting the demands for convergence, and the standalone vendors taking the tact that they, not LIMS, should control the QA/QC side of the equation. One marketing message I have followed with interest is the contention by some electronic notebook method execution vendors that, for the greater good of the customer, LIMS must either be lobotomized, or die completely.
• One argument being presented is that commercial LIMS are purely the product of customization, and most projects run horrendously over budget.
• Other arguments include the crudeness of LIMS to define and acquire instrument data as compared to method execution products.
• Still, other points include the inability of commercial LIMS to manage aspects of analyst qualification or instrument calibration.
• Last, some vendors list the dozens of personnel required to support a LIMS that supposedly would be alleviated by letting their electronic notebook run the show.

In the LIMS lobotomy scenario, LIMS is reduced to a simple, dumb, sample tracking database, and the overlord method execution software would call for certain chunks of information from LIMS when required. There is even a more outrageous suggestion that LIMS can be eliminated entirely, although that becomes an increasingly tough argument to make. In fact, even in the former example, the lobotomized LIMS, there remains a need to store several basic pieces of information in order for test results data to be entered, and these bits of information might be contained in tables. Perhaps analyst role definition, maybe test codes and specifications. If these are stored in local tables, with a table here and a table there, pretty soon you’re talking about a pseudo-LIMS.

So, the marketing of fear seems to carry the day. Fear of not being able to respond to an FDA audit, fear that projects will run obscenely over budget, fear that a LIMS project is nothing more than millions of lines of custom coding.

In fact, LIMS projects do run over. So did the completion of my basement, but it wasn’t because the tools weren’t available to do the work. LIMS projects, or method execution-layered-over-LIMS projects will also run over. The culprit is not the tools, it is the analysis (perhaps more appropriately, the analysts)…the approach, and the definition of requirements.

Are LIMS custom-coding projects? How long will the major LIMS vendors stay in business if that’s so? Not so long. Increasingly, the major vendors are providing tools and wizards that perform the brunt of the configuration work. Instrument interfaces can be done in minutes or hours, not days (or weeks) as they once were.

Is configuration required of LIMS? Of course. A commercial LIMS with expansive functionality must be formed into a system reflecting the business rules of a particular customer environment. If those business rules can be easily configured, the vendor prospers. If there is, in fact custom coding, they won’t. But every system must be configured, even method execution electronic notebooks.

Are LIMS bad at interfacing to instruments? Hardly. Beckman entered the game in the early 1980s, and they started right out of the blocks with instrument interfacing. Back at my old hovel, Digital Equipment Corporation, the LIMS/SM product circa 1984, had the Laboratory Transaction Processor for instrument interfacing. This was 25 years ago folks. These days, tight, bidirectional interfaces are available for some instrumentation, like chromatographs, and the selection of what should and should not be sent to LIMS is trivial.

As companies march toward a convergent platform of informatics functionality, so they too are marching toward more centralized deployments of harmonized systems. That means a single server or server farm, and users tapping into it over the Web via browser or the less elegant CITRIX Metaframe. So far, the pure method execution vendors are struggling to embrace centralized deployments with Web access, and fewer still have solved the elusive issue addressed by some LIMS vendors of how to manage instrument interfacing in a WAN environment.

So, now the turf wars begin. Imagine that you conceived of an approach, created market demand, but overstepped the logical boundaries of your architecture. It happened to Thomas Edison. Recall that, were it up to Edison, we’d all be living on direct current with power plants all over our neighborhoods. D.C. cannot easily be stepped up or down at a commercial level, and George Westinghouse and Nikola Tesla came on like gangbusters with alternating current technology. Huge voltages could be produced far away, and easily stepped down to manageable voltages where needed. Thomas couldn’t even take his light bulb and go home, and the D.C. dream of his meant potentially big money to Edison.

So, in the world of method execution, some vendors chose to form channel (partnering) relationships, or at least informal agreements with LIMS vendors. In this peaceful, daisy-filled landscape, those customers desiring method execution could buy a LIMS, and a method execution electronic notebook and would coexist in a harmonious, almost synergistic environment.

But some vendors inexplicably, possibly through unbridled passion or protectionism, decided to take on the LIMS vendors by suggesting their LIMS be put into a coma, awakened only to retrieve a few belongings such as sample IDs, or maybe just pull the plug on the LIMS entirely and start talking turkey with enterprise resource planning systems (ERPS).

Conclusion
I don’t know how this will work out in the end, but this is like the card game hearts: if you decide to shoot the moon in hearts, you damned well better have all the cards it takes. Otherwise, the crash is violent. Crystallizing this metaphor into the informatics universe, this means you had better present a compelling argument why a customer should buy (at least) two systems — a method execution electronic notebook and a LIMS — thus buying into two learning curves, support contracts and a hodgepodge of data spread over several locations. Alternately, you add so much functionality that you become a de facto LIMS, and then you’re thrown right into a cage match with the vendors who have played the game for decades.

Neither one is any more soothing than the hell-drive down I-70 out of the Eisenhower Tunnel.

Randy Hice is Director, Strategic Consulting at STARLIMS. He may be reached at editor@ScientificComputing.com.