How An IT Glitch Turned CVS Into A Meth Dealer
Written by Frank HayesA misconfigured CVS computer system originally designed to limit excessive sales of pseudoephedrine (which can be used to make methamphetamine) ironically had the opposite effect. More generic pseudoephedrine was sold in the drugstore chain’s southern California pharmacies than in the rest of its U.S. stores combined. The culprit? Store associates who regularly overrode or bypassed the system and—more to the point—the IT system that made it easy to do.
It’s always a challenge to get employees to correctly use a computer system that stops them from selling—even when it’s enforcing the law. That’s the kind of conflict retailers increasingly face in cases where, for example, loyalty programs clash with privacy concerns. No manager is going to get a bonus for pushing customers away. As such, it may fall to IT to make sure employees don’t cut corners, especially when those shortcuts could result in an expensive legal bill. Trouble is, that can be an impossible task.
In CVS’ case, these problems resulted in the drugstore giant being fined $77.6 million by California officials, the state announced last Thursday (Oct. 14). When the system was finally configured correctly, pseudoephedrine sales dropped by 87 percent in some Los Angeles CVS stores.
For the chain, IT looked like an obvious point of failure. According to prosecutors, CVS is required by federal law to limit sales of pseudoephedrine to relatively small quantities and to log the names, addresses and birthdates of all customers buying the drug. CVS actually installed software called MethCheck to do that in 2007, and the system is capable of tracking sales to each customer across all the chain’s stores. What it wasn’t configured to do was stop sales that exceeded the federal limit.
As a result, generic pseudoephedrine sales at CVS pharmacies in the Los Angeles and Las Vegas areas skyrocketed. As California drug-enforcement agents learned in late 2008 from people arrested for possessing large quantities of the drug, CVS was their preferred place to buy. State officials notified the federal Drug Enforcement Administration (DEA), which reviewed CVS’ sales practices and discovered that teams of buyers working for meth labs would sometimes literally clear a pharmacy’s shelves of the drug—and the MethCheck software wouldn’t stop them.
That’s bad. What’s worse is that pharmacy employees, who knew what the software was there for, didn’t stop the drug buyers either. It was hard for them to have missed buyers who made up to a dozen purchases per day in a single store—in one case, a customer made 10 purchases in less than an hour. (According to prosecutors, many of the buyers even used CVS loyalty cards to get credit for their purchases.)
And those were the (relatively) honest employees. At the other of the spectrum, one CVS manager bought pseudoephedrine on his own, using 36 different fake IDs. When he was arrested, he had almost $3,000 worth of pills that were worth 10 times that amount on the black market, according to a California state investigator.
October 21st, 2010 at 12:45 pm
That the CVS MethCheck software didn’t prevent all those illegal purchases is unfortunate and a bit of bad application design. That those at CVS responsible for replenishing those drugs at rates so significantly higher than the sell-thru’s at the remaining stores in their chain probably requires some comment. Application errors happen, unfortunately, but there was undoubtedly a variety of reports and other metrics available to the replenishment teams that were overlooked or, worse case, ignored. It’s difficult to believe that those associates did not know that they were replenishing a controlled substance.
October 21st, 2010 at 2:44 pm
Scapegoating IT folks is both wrong and misplaced. Also, the so-called software fix that CVS/MethCheck were forced into making was rendered useless in a matter of months by group smurfing and false ID smurfing of retail pseudoephedrine.
October 22nd, 2010 at 9:18 am
Rob,
Blaming IT is safe and easy. Nobody understands us anyway, and our face is that of a glass panel on a terminal.
October 22nd, 2010 at 9:25 am
Editor’s Note: There has been this undercurrent that the story was inappropriately blaming IT for this incident. As for blaming, the story did not say that it was some reckless act. It merely pointed out that the system was overly easy for rank-and-file employees to override. And given the fact that the incidents plummeted so quickly and so substantially when the software was tweaked certainly tends to substantiate the suggestion that the initial settings should have been different.
But that’s a far cry from saying that it was some reckless or evil act. It’s merely a heads up to some of the potential impact of how these settings are selected.
November 14th, 2010 at 7:55 pm
Re: Editor’s Note — Why is this regarded as an IT issue at all? The business unit / owner of whatever project implemented this requirement should be held accountable — they either didn’t supply the correct specifications or they did not test it properly before accepting it for production implementation.
Or are you expecting IT to catch all the blunders business units make in their specification or testing? Are you expecting IT to know the business requirements better than the business unit managers?