Inside Healthcare Computing has graciously agreed to make previous Mr. HIStalk editorials available from its newsletter as a weekly “Best Of” series for HIStalk. This editorial originally appeared in the newsletter in January 2007. Inside Healthcare Computing subscribers receive a new editorial every week in their Electronic Update.
Happy New Year! Considering the alternative, be glad that you were alive and well enough to eat and drink too much over the past couple of weeks. Now get back to work!
You’ll notice your local newspaper, having slyly given many of the real news staff time off for the holidays, is padding out their already-slim editions with time-insensitive material written in advance or copied off the wire services: witless phony New Year’s resolutions for local politicians, tired rosters of the biggest local stories and celebrity deaths of 2006, and pleas for donations to community causes.
I can see why. Healthcare IT news is sparse this time of year. No one wants to bring out new products, start implementations, hire or fire people, or make changes in the strategic plan when no one is paying attention (hmm: that would actually be good time to announce bad news, wouldn’t it?)
If our industry was a sport, the season would actually begin at the HIMSS conference in late February. It sets the tone for the year to follow, as everyone saves up positive announcements to coincide with the annual bacchanal. Vendors who make a bad impression at HIMSS will find it difficult to recover throughout the year, with attendees critically evaluating their demonstrations, booth size, staff attire, and cheery spirit or lack thereof. Even those companies in imminent danger of collapse spend the equivalent of a small country’s gross domestic product on one glorious, go-for-broke HIMSS splash, hoping against odds to get their money’s worth in new business.
Hospitals, too, get busy after months of letting IT projects lie fallow. No wonder ROI is hard to come by when projects come to a screeching halt because of non-IT staff refusal to get involved during (a) the November to January holiday block; (b) summer vacations; (c) school spring breaks; (d) impending JCAHO or state inspection visits; and (e) local, state, or national conferences involving anyone remotely involved. No wonder implementations take forever – they’re on hiatus half the year.
CIOs have plenty of work to do. All those clinical systems projects still need to be finished. Celebrate the completion of major phases with some downtime and reflection, don’t forget to keep pushing at needed process changes and system improvements, and then jump into the next round of work. Clinical systems projects are like painting the Golden Gate Bridge: they’re never finished.
Speaking of clinical systems, if you haven’t yet made a commitment to bedside barcode verification of medications, then now’s the time. Same, too, with tightening up your Pyxis access with biometric security, override vigilance, and double-checked stocking procedures.
Microsoft has a new operating system and Office version – yay! Users will be upgrading at home, scornfully wondering why your IT department is holding them back in the Stone Age with systems they shamefully underuse anyway. You needed that non-strategic headache, right? At least PC hardware keeps getting cheaper, right about the time Vista will eat up more of it.
RHIOs will want your attention in 2007. Your data, too. Maybe now’s the time to catalog all the electronic data elements you have available and to develop a plan to move important paper-based ones to electronic formats.
If you haven’t already, let one of your computer geeks play around (officially) with Linux, both server and desktop. If you aren’t running it at all now, you will be soon.
Stark relaxation means you may need to support a new class of impatient, computer-illiterate users: doctors in private practice and the inconsistent employees they hire. Keep stats to get budget dollars since those support hours have to come from somewhere.
Lastly, if you’re in management, please make sure to recognize and reward those who work for you. When you get too full of yourself, make a list of which essential personnel would be needed in case of system failure, natural disaster, or clinical emergency. You’re probably not on it.
I hope our industry and all of us working in it have an excellent 2007. If in doubt about a particular course of action, remember WWIWAAP (which you may pronounce WEE-WEE-WAP, since I just made it up): what would I want as a patient?
This editorial is copyright-protected by Algonquin Professional Publishing, LLC., publishers of Inside Healthcare Computing. Please do not copy, forward, or reproduce this material without prior permission. To obtain permission or for more information about Inside Healthcare Computing’s reprint policy, please contact the Customer Service Department at 877-690-1871 or go to http://insidehealth.com/ihcwebsite/reprints.html.
Mr. HIStalk’s editorials appear each Thursday morning in the subscribers-only version of Inside Healthcare Computing’s E-News Update. To subscribe, please go to: https://insidehealth.com/ihcwebsite/subscribe.html or call 877-690-1871.
Inside Healthcare Computing has graciously agreed to make previous Mr. HIStalk editorials available from its newsletter as a weekly “Best Of” series for HIStalk. This editorial originally appeared in the newsletter in December 2006. Inside Healthcare Computing subscribers receive a new editorial every week in their Electronic Update.
I’d never heard of the Clinical Data Interchange Standards Consortium (CDISC) until last week. That’s when that group announced the kickoff of a new interoperability project, this one involving linking EMR systems to the information systems of clinical investigators who are performing drug or disease research. The audience might be researchers, the Centers for Disease Control and Prevention, or registries for patients or disease. The IHE is involved in the testing and will demonstrate the results at the HIMSS conference.
I’m not usually interested in this sort of project. I’ve seen first-hand what an insurmountable effort it can be just to get hospital systems to swap clinical data across the hall, much less with national third parties. Still, this is an exciting indicator of how quickly the now-common idea of interoperability has taken hold. If nothing else, RHIOs have made hospitals think about the value of their patient information and how to exchange it in a standard electronic format.
Getting and keeping drugs and devices on the market is expensive and information-intensive. Several small, highly profitable companies have sprung up to help enlist patients in studies, to do the rigorous paperwork required, and to design research methodologies. Their key commodity is information.
Hospitals have patient information that’s available nowhere else, the kind that arouses researchers and manufacturers with far deeper pockets. Repurposing that existing information by making it available to those willing third-party customers, even when motivated purely by mission-supporting cash, is at least more beneficial to society than running a McDonald’s or building medical office buildings.
Let’s say your hospital implements a well-integrated, information-rich EMR system that can easily tie together everything about patients from medical history to demographics to procedure history. Suppose you add genomic data to the mix, storing information about family history, lifestyle, and a longitudinal history of disease, treatment, and outcomes. All of that could be used to the advantage of your own patients and institutions, but it has an equally high value to those third parties trying to assemble or execute big research projects.
Drug companies and device manufacturers need the data that lives in your clinical systems. How else will they be available to target research to a very narrow range of patient types, maybe even those with a specific genomic profile? It could help them identify appropriate research subjects, design post-marketing surveillance, study population-based outcomes, and catalog adverse events. The information you provide could either be de-identified or made available only if individual patients opt in. The benefit to patients is access to a wider variety of treatments and protocols, most likely free to them if tied to a research project.
You wouldn’t just give that information away, of course. Hospital information is far deeper and more detailed than what’s available from any other source, with a wide scale to match. All you need is sophisticated EMR functionality and a relentless push to get every scrap of clinical information codified, categorized, and cross-referenced.
In the movie Wall Street, Gordon Gekko says, “The most valuable commodity I know of is information.” That is true of clinical data, especially when those who value it can afford to pay. Just don’t sign away too cheaply the rights to your treasure trove of data, even if the interested customer is a RHIO or third party data vendor.
This editorial is copyright-protected by Algonquin Professional Publishing, LLC., publishers of Inside Healthcare Computing. Please do not copy, forward, or reproduce this material without prior permission. To obtain permission or for more information about Inside Healthcare Computing’s reprint policy, please contact the Customer Service Department at 877-690-1871 or go to http://insidehealth.com/ihcwebsite/reprints.html.
Mr. HIStalk’s editorials appear each Thursday morning in the subscribers-only version of Inside Healthcare Computing’s E-News Update. To subscribe, please go to: https://insidehealth.com/ihcwebsite/subscribe.html or call 877-690-1871.
Inside Healthcare Computing has graciously agreed to make previous Mr. HIStalk editorials available from its newsletter as a weekly “Best Of” series for HIStalk. This editorial originally appeared in the newsletter in July 2006. Inside Healthcare Computing subscribers receive a new editorial every week in their Electronic Update.
My colleague Ross Koppel, a sociologist and Penn professor, wrote an editorial in The American Journal of Managed Care (released today) titled “Defending Computerized Physician Order Entry From Its Supporters.” In it, he stresses that CPOE and clinical decision support systems (DSS) are separate systems, despite popular perception. Their implementation is often divergent and their benefits and shortcomings confused (or intentionally misrepresented).
Ross is right, and his sociologist’s view is important to our little world of geeks and IT-friendly doctors. We’re expecting a lot from immature CPOE and DSS systems that most hospital executives can’t define, even when they’re plunking down hard-earned capital dollars for them.
I should mention that Ross wrote another article awhile back that riled up vendors, consultants, and HIMSS, in which he described one hospital’s increased error rate with CPOE implementation, finding that his one, small discouraging word was met with choruses of indignation from the “CPOE is Nirvana” crowd.)
CPOE is a smart typewriter that, standing alone, has little ability to improve patient outcomes. It prevents transcription errors, although those seldom harm patients because they’re caught anyway. CPOE makes it easy to choose common order defaults instead of “winging it.” Beyond that, the benefits (both clinical and financial) come from DSS, not CPOE, even though the hospital executives signing a multi-million CPOE deal as their cornerstone of patient safety automation probably missed that point completely.
DSS systems are, unfortunately, mostly frightfully immature, even more so than CPOE. Early adopters share war stories of sky-is-falling alerting, inflexible third-party rules, the inability to customize and personalize, and performance-sapping rules engines incapable of delivering alerts of any more sophistication than the old hard-coded screen edits.
Still, the real problem is right down Ross’s alley. Hospitals usually buy CPOE and DSS because they’ve failed to control physician behavior otherwise, often euphemised as “reducing practice variation” or “practicing evidence-based medicine.” They want software to do the dirty work that they can’t or won’t: telling physicians that they’re wrong and forcing them to change. When docs don’t follow the new cookbook medicine rules any better than the old ones, CPOE and DSS get the blame and everyone involved in the project pretends to have been somewhere else when the vote was taken to buy it.
I’ve been involved in two CPOE/DSS implementations, both involving large IDNs and well-known vendors. In both cases, hospital administration ill-advisedly shot their patient safety technology wad on CPOE, confident that it would improve patient care better than any other investment. Physician adoption was universal in one, minimal in the other, but one element was common to both: 90% of the expected DSS benefit never materialized. The carefully but naively drawn up list of post-implementation metrics was hidden away once everyone realized that we hadn’t really changed anything of importance for our multi-million dollar investment. We had bought ourselves a smart typewriter.
No software contains a switch that turns resistant physicians into docile, rule-following sheep who make better decisions under the watchful eye of Big Brother’s can’t-miss medical guidelines. But if your hospital has already spent a few million on CPOE and DSS thinking that was the case, you’ve learned that already.
Maybe the next generation of systems will offer value that physicians recognize. After all, they want the best outcomes for their patients, too. Where they disagree is that we have the answer right now with these first-generation CPOE and DSS applications.
This editorial is copyright-protected by Algonquin Professional Publishing, LLC., publishers of Inside Healthcare Computing. Please do not copy, forward, or reproduce this material without prior permission. To obtain permission or for more information about Inside Healthcare Computing’s reprint policy, please contact the Customer Service Department at 877-690-1871 or go to http://insidehealth.com/ihcwebsite/reprints.html.
Mr. HIStalk’s editorials appear each Thursday morning in the subscribers-only version of Inside Healthcare Computing’s E-News Update. To subscribe, please go to: https://insidehealth.com/ihcwebsite/subscribe.html or call 877-690-1871.
Inside Healthcare Computing has graciously agreed to make previous Mr. HIStalk editorials available from its newsletter as a weekly “Best Of” series for HIStalk. This editorial originally appeared in the newsletter in February 2007. Inside Healthcare Computing subscribers receive a new editorial every week in their Electronic Update.
One reason we hospital IT types aren’t taken seriously is the “grocery story” analogy. You know, when some well-meaning government official, non-healthcare CEO, or your next-door neighbor smugly proclaims, “There’s more automation in the grocery story checkout line than in most hospitals.” Ha, ha, what an insightful observation – first time we’ve heard that one.
Randy Spratt, McKesson’s CIO, recently trotted out the old warhorse in an interview with Fortune. I’m sure his intention was benign (i.e., “buy more of our barcoding stuff to enlarge my executive bonus”) but perhaps his lab systems background makes him insensitive to how steamed nurses get when someone trivializes the barcode verification process on their end. If it were easy, everyone would be doing it.
(Hint to Randy: those same nurses are often involved in barcode system selections, with one of their possible choices being your employer’s own AdminRX product, currently running last in a three-horse KLAS barcoding product race. Better stroke them a little next time.)
Ann Farrell, BSN, RN and Sheryl Taylor, BSN, RN sent me a list of why the grocery store analogy is not only inappropriate, but offensive to nurses. Their list was detailed, persuasive, and passionate, so naturally I decided to go more for the ironic and humorous with my own imitative list. Theirs will be published, I believe, and they’re working with HIMSS people and that same Fortune magazine. Until their more authoritative tome sees daylight, this will be your amuse-buche.
If grocery stores were like hospitals:
- They would buy Doritos by the bag, but would have to repackage and label individual chips, and then track every chip – who bought it, who ate it, and whether they ate it in an appropriate quantity and with only complementary foods and according to dynamically calculated nutritional needs.
- They would have to set up an internal barcoding factory since grocery makers would refuse to barcode their products until all stores collectively agree to pay extra.
- Each clerk would serve 15 checkout lanes simultaneously.
- Every customer would enter the store at precisely 9:00 a.m., 1:00 p.m. and 6:00 p.m., but having any of them wait more than 15 minutes is a fireable offense.
- It would be the clerk’s job to prevent customers from buying both Doritos and potato chips since they serve the same purpose.
- Barcode scanners would be so poorly designed that clerks would need a full two days of training to use them.
- Stores would not be self-service. Instead, clerks would take the customer’s list, try to decipher their illegible handwriting, and run around the store to assemble several such orders for different customers at the same time. Each item would have to be documented twice: one when pulling it from the shelf and again when giving it to the customer. Customers would be encouraged to change their lists constantly. Most stores would not have the capability update the clerk’s list electronically, so items would be scratched off and handwritten on the same ratty sheet of paper.
- Somber-looking inspectors could show up unannounced demanding to see a list of customers who bought hot dogs in the last year or the complete grocery purchases of a specific person named John Smith, but only the right John Smith.
- Clerk supervisors, exasperated over loss of productivity, would suggest keeping paper copies of commonly used barcodes to save time over scanning the real thing.
- Instead of wheeling their cart to the checkouts, customers would ring the little “I need help” button wherever they happen to be, requiring the clerk to lug the cash register to their location to scan their item.
- The loyalty card of every customer must be scanned before selling them anything, even if they showered with it and ruined the barcode.
- Soda would be sold like paint – the clerk would have to mix and label whatever flavor the customer wants using stock ingredients.
- Once barcodes are scanned, instead of being recorded electronically, the information would print a duplicate receipt to be filed forever.
- Clerks who ring up the wrong price could kill the customer, would be barred from future clerk jobs, and could be jailed.
- When working alone in a 24-hour store after everyone else has gone home, the clerk would cut meat, mop the floors, make pastries, unload the truck, show compassion, attend to family needs, and humor abusive superiors who take credit for accomplishments that mostly occurred while they were offsite making ten times what the clerk is paid.
This editorial is copyright-protected by Algonquin Professional Publishing, LLC., publishers of Inside Healthcare Computing. Please do not copy, forward, or reproduce this material without prior permission. To obtain permission or for more information about Inside Healthcare Computing’s reprint policy, please contact the Customer Service Department at 877-690-1871 or go to http://insidehealth.com/ihcwebsite/reprints.html.
Mr. HIStalk’s editorials appear each Thursday morning in the subscribers-only version of Inside Healthcare Computing’s E-News Update. To subscribe, please go to: https://insidehealth.com/ihcwebsite/subscribe.html or call 877-690-1871.
Inside Healthcare Computing has graciously agreed to make previous Mr. HIStalk editorials available from its newsletter as a weekly “Best Of” series for HIStalk. This editorial originally appeared in the newsletter in February 2007. Inside Healthcare Computing subscribers receive a new editorial every week in their Electronic Update.
As a hospital IT person, I would never sign a vendor’s software contract without protecting my organization with a variety of specific and severe contractual penalties. From recent Inside Healthcare Computing articles, many or most hospitals sign penalty-free contracts. I’m shocked. I like vendors, but money makes people (and companies) behave badly.
Vendors (software or otherwise) can tell you anything they want about their product’s performance and reliability. That can have one of three possible outcomes:
- If the company is both knowledgeable and honest, you will be pleasantly unsurprised when their product works as advertised, but at least you won’t be caught unaware by a major meltdown. That’s the best outcome.
- If the company is honest but doesn’t have broad enough experience with their product in a setting like yours, you’ll probably be miserable together, hoping they’re as responsive as they are honest. That’s bad. Sometimes you hit architecture or design flaws that can’t be fixed.
- If the company is lying or has wildly oversold their wares, nothing else matters because you’ve been suckered into a long-term, expensive, and contentious relationship with a company that has already demonstrated its willingness to take your money under false pretenses. That’s the worst.
For all three outcomes, your first line of defense is due diligence. Don’t whip out your checkbook until you’ve taken extensive site visits (of your choosing, not the vendor’s), performed acceptance testing, and documented every promise and important capability in a binding contract. Buying from a demo is just plain stupid.
The biggest mistake hospitals make is finding problems with previous implementations, but then buying the product anyway. The most common rationalization: “We’re smarter than those rubes who couldn’t make it work, plus we really like the product and the salesperson.” That combination of naiveté and misplaced bravado has lined many a sales rep’s pocket. It often benefits an executive recruiter, too, since the CIO who ignores a product’s well-known, spotty history often has plenty of free time to reflect after he or she has been shown the door.
Vendors may not be thrilled to see the list of penalties you want, but they’re not your best buddies. They’ve got their best possible price and terms. So do you. You both have the same job: to meet somewhere in that middle ground after fighting over what’s left between those numbers.
You can be chums when selecting a product and again after buying it, but not while the deal’s on the table. If the vendor doesn’t hate you during that time, you’re not pushing them hard enough.
Contracts without penalties are binding only to the customer. If the software fails to provide value, crashes constantly, or can’t be used like you were told, you still pay unless you were smart enough to write in penalties. Your want their skin in the game with yours.
The most important eventualities to cover with penalties:
- If the software doesn’t do what you were promised in a way that makes it unusable.
- If you have problems that will cause you the most harm: downtime, poor response time, or cancelled development plans.
- If the software or vendor has weak areas that sound like trouble. If the vendor’s teeth clench up when you lay out penalty terms for failing to deliver a richly functional ED package or a CPOE-to-pharmacy interface, maybe they don’t really plan to.
Penalties and payments go hand-in-hand. Your contract should require lots of the former and none of the latter if performance slips. Without penalties, you have no leverage. Vendors know you won’t yank a CPOE system if they have a major bug that could cause patient harm. A hard-hitting, predefined penalty is your best hope for getting their undivided attention to fix it. The cash won’t be much consolation, but it’s a hammer to hit the vendor over the head with.
I know we all like to throw harmless little love words around like “partner” and “shared vision.” Vendors pretend to be wounded when you sully the honeymoon bed with legal assurances. Take a lesson from Paul McCartney – maybe the vendor is a wonderful partner who loves you for something other than your money, but make them sign an air-tight prenuptial agreement just in case. Secretly, they’ll admire you for it.
This editorial is copyright-protected by Algonquin Professional Publishing, LLC., publishers of Inside Healthcare Computing. Please do not copy, forward, or reproduce this material without prior permission. To obtain permission or for more information about Inside Healthcare Computing’s reprint policy, please contact the Customer Service Department at 877-690-1871 or go to http://insidehealth.com/ihcwebsite/reprints.html.
Mr. HIStalk’s editorials appear each Thursday morning in the subscribers-only version of Inside Healthcare Computing’s E-News Update. To subscribe, please go to: https://insidehealth.com/ihcwebsite/subscribe.html or call 877-690-1871.
