Time Capsule: Your Co-Workers Are Your Biggest IT Security Problem

I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).

I wrote this piece in June 2006.

Your Co-Workers Are Your Biggest IT Security Problem
By Mr. HIStalk

I’ll bet that every hospital in the country has had sensitive information fall into unauthorized hands at least once. The VA, big banks, and universities have skilled security teams to prevent employees from exposing data, accidentally or otherwise. If those large organizations can’t control breaches, the average hospital doesn’t have a chance.

Health care organizations have spent years and hard-won dollars trying to catch up to the IT standards of other industries, where nearly all employees have enjoyed easy access to PCs, e-mail, and both wired and wireless networks. However, once the green-screen terminals went away, so did the last chance to keep confidential data secure. Data convenience is both a blessing and a curse.

CIOs and network engineers spend hours trying to out-think shadowy foreign Internet hackers when the real problem involves the co-workers they pass in the halls each day.

Employee security policies provide a false sense of security. The headlines scream that information on 26 million veterans has been breached, not that the VA had a great policy broken by a rogue employee who took data home without authorization, only to have it stolen.

Employees may drag laptops or USB drives home because their employer doesn’t have a good remote access solution to let them work from home. Perhaps backups are unreliable, leading cautious staff to create their own. Maybe software policies or budgets are so limited that common productivity tools aren’t available, making it tempting to load data onto the family PC. Whatever the reason, employees are breaking the rules.

Accidental data loss is bad enough, but one study found that 70 percent of employees have stolen electronic data from their employer, most often in the form of e-mail lists, databases, and documents. The most common reason: to help them get a new job. Three-fourths of those surveyed didn’t see anything wrong with that, especially if the employee helped create the information in the first place.

Security technology can help, but it requires tough decisions. Most hospitals don’t have the budget or organizational willpower to disable USB ports, remove CD-RW drives and floppies, buy encryption software, and install physical locks on laptops. Even if they did, web controls are inadequate to prevent using Hotmail accounts or online file storage that provides a non-hardware method of moving data to unauthorized locations. For that matter, there’s that old security hole called a “printer.”

Maybe the best security policy is to avoid storing anything that would be useful to someone else. People get paranoid about their medical information, but it has little monetary value (unless you’re a celebrity or political candidate). A hospital’s internal documents and policies probably aren’t all that interesting to competitors, but you might reconsider storing Social Security and credit card numbers.

The good news is that the recent health care-related breaches have been accidental, where well-meaning employees screwed up. For that reason, I’d put my IT security money into employee education, awareness, auditing, and protection tools for laptop users instead of obsessing over Boris and his hacking team. That’s the best hope of staying out of the headlines.

Even then, I’d develop a damage control plan for a breach. There’s a good chance it will get used.

Time Capsule: USB Drives Would Help Consumers Quickly Access McClinics

I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).

I wrote this piece in May 2006.

USB Drives Would Help Consumers Quickly Access McClinics
By Mr. HIStalk

You’ve seen the flurry of recent news. Your local Wal-Mart, Target, or chain pharmacy will soon offer basic medical care through in-store clinics.

It’s a low-friction process. If you wake up with strep throat, you just head over to your local store and quickly see a nurse practitioner or physician assistant. Maybe $60 and 20 minutes later, you walk out with a prescription, having avoided the tedium of sitting in a cheap chair and stealing glances over your 2004 Newsweek to guess what’s wrong with everyone else in the room.

Most of us don’t have a firm relationship with a primary care physician, so drive-through McMedicine will suit us just fine. Just gimme the prescription, please, and let me get on with life.

Since these casual liaisons will take mere minutes, handling the dreaded “new patient” forms will be the biggest waste of time for both patient and clinic. You laboriously write everything down so they can re-enter it into their systems, even though you may never cross their door again (hopefully, each brand of clinic will at least share their EMR data nationally among themselves, like the drug chains do for prescriptions).

Here’s an alternative that I think has great possibilities. You enter everything in advance on your PC, saving it to a USB memory drive. Bring that along when you impulsively drop by the McClinic and hand it over to the receptionist. You’ve saved everyone time and reduced the chance of error. Maybe you even get to jump ahead of the guy hunched over the clipboard.

What the clinic needs is an interface to my gadget. They shouldn’t have to print and re-enter everything that I’ve already given them in electronic form. They should be able to plug in the device and press an import key in their EMR. Why not? A universal standard for exchanging basic personal health record information should be a slam dunk compared to all the other interoperability challenges ahead. You create and maintain your own information in one place — just bring it along.

Since electronic information saves the clinic time, it could encourage customers by providing free data entry software, and maybe throwing in a cheap USB key-ring drive with security features. That encourages brand loyalty, much like grocery store member cards. They could even update your device as you leave with encounter information, including instructions and information links.

This model has more opportunities to new consumer health care players like Intuit and Microsoft than the usual clipboards and copy machines. It also places consumers in control.

We’re moving toward a provider system that looks more like that of chain pharmacies, with a variety of interchangeable providers competing for customers. The big boys want to play in our sandbox — companies that value customer convenience, low cost, and competitive advantage a lot more than the current players.

Universal EMR interoperability at a national level isn’t coming anytime soon. Consumers are scared of the Internet when it comes to health care privacy. This system of having patients walking around with their own information ready to plug into a provider’s system seems like the best solution for now. If I were running a chain of these clinics, I’d jump all over it to beat my competitors.

Time Capsule: Vendors Should Make Software That Crusty Night-Shift Nurses Can Love

I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).

I wrote this piece in May 2006.

Vendors Should Make Software That Crusty Night-Shift Nurses Can Love
By Mr. HIStalk

I wasn’t surprised by a recent study’s seemingly conflicting results. Nurses see themselves as key players in patient safety, yet admit that they often break the very rules created to keep patients safe, such as checking a patient’s identity by two methods before giving meds.

Nurses continually amaze me in two ways. They are stunningly caring and comforting to the frightened and hurting patients under their care. They are also terrible computer users.

Before I get lynched by nurse readers, allow me to present my flimsy and anecdotal evidence. I’ve known at least 500 nurses over the years in my clinical and IT roles. Almost none of them were interested in programming or were capable of fixing basic PC problems. Looking over their computer shoulder is like watching your kid play tee-ball – you try to help them by sending powerful telekinetic messages (“Press Shift-Tab … Shift-Tab”) or with surreptitious body English.

It just doesn’t come naturally. The “caring” part of the brain has some sort of limbic dominance over the “nerd center.” That’s quite unlike lab techs, pharmacists, and physicians, who love creating databases and playing around on the Internet.

It’s great news as a patient that few nerd nurses are out there comforting the dying and cheering up sick kids. It’s not so encouraging to systems vendors.

Nurses don’t think in black and white. They bend or break the rules whenever it makes sense. Their numbers and organizational structure ensure they’ll be hard to reach and harder to convince, especially when they’re being asked to change their routine. They know they’re in short supply, so you can’t scare them into compliance.

Along comes software, which is about control, reduction in variability, and elimination of individuality (management in a box, in other words). Nurses hate that stuff. For example, the No. 1 problem with bedside bar-coding systems is nurses who copy patient wristbands so they don’t have to scan the real thing before giving meds. (I don’t get it either, but I’m sure there’s a reason on the front lines.)

The primary users of our clinical systems are nurses. Nerd-designed systems don’t make sense to them, even if slightly higher nerd-center developed nurses (a.k.a. informatics nurses) advised them.

Few industries have professionals on the front line, and even fewer expect them to be competent users of a wide variety of software and technology. We roll out software with poor user design and “in your dreams” workflow. We cut training because we can’t spare the time away from patients. We use software as an enforcer of rules already being ignored, then we throw in a few new ones because that’s what software does. The end result is an application that’s underused, misused, and blamed for a reduction in quality.

Providers are unlikely to hire nurses based solely on computer skills or willingness to follow orders (software or otherwise). For that reason, software needs to be designed for the average nurse, paying attention to usability and task-based design.

Instead of the friendly audience of IT or management nurses, vendors and providers should seek counsel from the crustiest, most cynical night-shift nurse who just wants to be left alone to care for patients and then go home to lead a non-computer lifestyle. Maybe the end result would be software that even a nurse could love.

Time Capsule: Medical Equipment Sales Boom While Health IT Struggles

I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).

I wrote this piece in April 2006.

Medical Equipment Sales Boom While Health IT Struggles
By Mr. HIStalk

GE Healthcare just announced quarterly profits of nearly half a billion dollars. While much of that came from diagnostic equipment sales, it’s still worthy of reflection — whether you helped boost the company’s bottom line through your purchases or whether you have to compete against them.

An interesting phenomenon occurs on the non-IT side of healthcare technology. Vendors of diagnostic imaging equipment and Star Wars-like treatment gadgetry use a little bit of science and a lot of scientifically-designed propaganda to create demand for the latest Gamma this, 64-slice that. Customers plant public relations articles in the local newspaper, bragging on their new toy with a subtle message: “Our competitors are cold-hearted cheapskates for not shelling out for the cool patient care stuff like we do for you.”

What’s the downside?

1. In many cases, the equipment has no proven benefit for patients. Seeing an image more clearly doesn’t necessarily mean anyone gets better faster.
2. Supply creates its own demand, ensuring that all those new private office MRI machines are humming from constant use on patients who didn’t need it until Doc got his first invoice.
3. More billions in costs are piled onto a poorly performing healthcare system.

So how can GE, Siemens, Philips, and other conglomerate vendors make so much money on this stuff and still not necessarily make much of a dent in healthcare IT? More specifically and paradoxically, why are customers so willing to spend millions on a given company’s non-IT technologies while fighting tooth and nail to avoid using that same vendor’s IT products?

The most obvious reason is that providers can make money by running expensive tests, particularly when coached by vendor reimbursement experts who can influence the companies who write the checks (and who eventually increase premiums in response). The patient’s not paying anyway, so everybody’s happy, at least until the next round of healthcare and insurance cost increases.

The science behind this equipment is often no better than the shaky anecdotal suppositions about CPOE or ambulatory electronic medical records. Still, it creates its own demand, mostly because customers have a financial incentive to fit it into their practice, while those other IT technologies are largely ignored and unsuccessful because they require extra work for no extra payment.

The takeaway message is that, science aside, doctors and hospitals will utilize the hell out of something when they’re paid to do so (equipment, drugs, supplies, and for-profit referral centers). While it’s nice if patient care is improved, it’s only mandatory that it not be worsened.

Few health IT technologies have ever caught on that didn’t benefit users directly. The stuff being touted today (RHIOs, CPOE, clinical decision support) doesn’t, so it wallows around with unenthusiastic little pockets of interest here and there. The cheerleaders keep complaining about low adoption and the need for someone else to pay for it.

If providers were paid to reduce utilization and improve outcomes, advanced IT support would be demanded, not refused. Until then, the conglomerate vendors will thrive on the medical equipment side and struggle on the IT side unless someone bribes customers to get on board.

Time Capsule: Before You Buy, Look at the Impact on User Productivity

I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).

I wrote this piece in April 2006.

Before You Buy, Look at The Impact on User Productivity
By Mr. HIStalk

A story often repeated: a big organization executes a high-profile rollout of a clinical system, but caregivers say it takes longer to use. They deliver an ultimatum — either you accept a reduction in productivity or you ditch the system.

The latest subject is the Department of Defense, whose new $1.2 billion AHLTA system (which is actually the renamed old system, CHCS II) is claimed by users to be so slow that they have to reduce their patient schedules by one-third. Patients are being diverted to emergency departments and routine checkups aren’t being done.

Maybe this is telling us that we don’t look hard enough at a system’s impact on user productivity. I don’t recall ever having heard of a health care organization that measured how long it takes to write an order, document care, or write a prescription, comparing times before a system install and after. I’ve never heard of someone choosing a particular system because it’s faster for the caregiver, or in many cases, even giving the caregivers a peek at it before the decision to buy is made.

I’ve also not heard of an organization budgeting additional staff to offset reduced productivity with automation. The reason is there’s not supposed to be any slowdown. Everybody knows that computers improve productivity, right?

If that was the case, all those PCs that hospitals have deployed would have caused huge staff reductions. I haven’t heard of that either. Sales prospects are easily impressed with unrealistic projected staff reductions that never seem to materialize.

It gets worse when users are hard-to-find licensed staff, such as nurses or pharmacists. A system that takes up more of their time, no matter what benefits it provides to someone else, may create a staffing dilemma that directly impacts patient care.

This is a customer problem, not a vendor problem. If customers demanded productivity gains for their users, vendors would respond (or lose business). This goes back to a generally casual regard for usability testing — never a priority in the mainframe days and not improved very much since in health care.

Local configuration options make it hard to evaluate an off-the-shelf vendor system upfront to determine workflow impact. You could ask the vendor’s customers, though. Arrange to time how long it takes to chart a med as given, to create a progress note, or to enter an order set as a physician. Then, compare that with the time required by your current process.

You don’t need the vendor’s help to do this. You might want a management engineer to look over your shoulder for consistency in measurement. Otherwise, all it takes is for hospitals to talk to each other, which they’re usually pretty good about doing.

I don’t know about you, but I’d rather not be in the hot seat to answer this question from clinicians — do you want us to take care of patients or to use your system?

Time Capsule: If You Want Testing For Usability, Reliability and Maintainability, Tell CCHIT

If You Want Testing For Usability, Reliability and Maintainability, Tell CCHIT
By Mr. HIStalk

I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).

I wrote this piece in April 2006.

I wrote an Inside Healthcare Computing column in January that lauded the work of the Certification Commission for Healthcare Information Technology (CCHIT). I said then that CCHIT has the clout and objectivity to become the EMR industry’s Consumer Reports. The commission only needs to broaden its emphasis beyond interoperability, functionality, and security to include areas such as patient safety and usability.

The American Hospital Association recently made a similar recommendation, asking CCHIT to evaluate basic EMR product architecture components such as usability, reliability, and maintainability. AHA wants CCHIT to worry less about interoperability between organizations and instead measure how well systems within an organization (clinical ancillary applications, for example) exchange information.

Bravo to AHA on several counts. First, AHA recognizes that CCHIT is the right group at the right time.

Second, AHA understands that RHIOs are like railroad tracks. The best way to crisscross the country is to develop standards and then have teams working from both ends, meeting in the middle twice as fast. CCHIT standards that address data management within the four walls will prepare organizations to feed the data demands that RHIOs will create. As I’ve said before, a RHIO without data-ready members is like TV cable with no programs.

Third, AHA must be listening to its member hospitals, who frankly complain a lot about IT without really helping the situation — buying products with known weaknesses, poorly managing their own implementations, and failing to rally the troops around real workflow changes. AHA is wisely (and maybe contritely) asking for help, making IT a showcase issue.

Lastly, AHA’s request comes at exactly the right time, as litanies of unsuccessful implementations cloud the sunny skies of national electronic hand-holding. Uninformed customers (not necessarily the fault of vendors) play a significant part in this nearly universal failure of products and their users to provide the lofty benefits everyone expects.

CCHIT should be proud of its work so far. This rather amazing de facto endorsement of it as the impartial overseer of a marketplace widely recognized as imperfect is good for both vendors and customers. Vendors can take the money and run today, but an environment in which the highest customer-rated product gets a six or seven on a 10-point scale is not sustainable. The market will either get better, smaller, or both.

If you agree with the recommendation that the certification process for inpatient systems should include tests of a product’s usability, reliability, and maintainability, I urge you to write to CCHIT at info@cchit.org. The more people in the industry that the commissioners hear from, the more likely they’ll take our needs seriously.

I can’t recall a time in health care where any group (government or private) has had so much hope dropped into its lap so quickly. The correct response from the Office of the National Coordinator for Health Information Technology and CCHIT is this: thanks for the vote of confidence, we accept that responsibility. Surely it wouldn’t be that expensive and doesn’t have to take away from the government’s interests.

Time Capsule: Small Vendors With Good Ideas Can Carve a Niche In Healthcare

I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).

I wrote this piece in March 2006.

Small Vendors With Good Ideas Can Carve a Niche In Healthcare
By Mr. HIStalk

A just-announced study found that Michigan’s CPOE adoption rate of about 10% is nearly double the national average. I thought about how I would read those results if I were a software vendor unfamiliar with healthcare. Would I see health care as a market ripe for new entrants? Or would I steer clear of what looks like a mature market with low potential for growth due to poor customer acceptance of the 10 or so available CPOE products?

Assuming for a moment that the market is attractive, how would I compete with the big healthcare vendors? I’d need a fast development cycle, reference sites, and leverage from existing technologies. That rules out applications like CPOE, ERP, nursing documentation, surgery, and patient billing. Those are long, ugly slogs for both the vendor and the customer.

Healthcare has a few products that enjoy high acceptance: PACS, laboratory systems, AP/GL, HR information systems, online clinical references, and wireless networking. Those require a lot of domain expertise and development, however, and those markets already have entrenched players. Pass.

As a vendor, I want to make money. Healthcare seems to be one of few industries in which vendors of expensive software still can’t turn a profit in many cases.

So what’s left? My best ally as a little guy is innovation. It’s uncommon in healthcare IT, whose longstanding culture is more mainframe than MySpace. That means I should:

• Build something that supports what healthcare users themselves want to do, not what someone else wants them to do. Sounds obvious, but think about CPOE, nursing documentation, and other software that forces change on users who don’t want it, often leading to fierce resistance and vendor acrimony.
• Create a product around off-the-shelf technologies that can be tweaked into a healthcare-specific package. By now we should have seen more healthcare applications built around office suites, voice over IP, Intranets, search engines, knowledge management, and instant messaging.
• Build something that isn’t stodgy and dead serious. Think Google or Skype instead of Invision or Star. When’s the last time you saw a “cool” healthcare application with devoted admirers?
• Sell your product shrink-wrapped, or nearly so. The last thing healthcare customers need is another cadre of consultants that cost more than what they’re installing.
• Price for volume, not the once-a-year home run. Lower prices mean shorter sales cycles and a lower level of approval authority. Market penetration means more opportunities for add-ons and upselling.
• Provide flexibility without customization or automate areas where processes are consistent. If you can build a system that even 20% of hospitals can use as-is, you’ll have more customers than you can handle.
• Target your decision-makers. Who has the influence needed to get your product in the door? In hospitals, that’s usually predictable (the nursing vice president — no; the finance vice president — yes). Can you reach them easily and explain your concept in a paragraph or two? Is the number of people affected small enough so that concerns about upheaval are minimized?

The Michigan study tells me to forget CPOE and carve myself a niche. The big vendors are locked in long, messy implementations of aging, high-ticket products, often trying to keep Wall Street and/or conglomerate parents happy rather than delighting customers with fresh thinking. Someone with good ideas and low overhead might be able to build a nice little business from the crumbs they drop.

Time Capsule: Information Technology Can’t Easily Fix Health Care System Gaps

I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).

I wrote this piece in March 2006.

Information Technology Can’t Easily Fix Health Care System Gaps
By Mr. HIStalk

A New England Journal of Medicine study last week found that ethnicity, income, insurance status, and geographic area do not influence the preventative care received by Americans. Great news! Well, not entirely — we’re collectively getting only about half the care we should. The embarrassing gap just isn’t prejudicial, that’s all.

The study used a RAND Corporation list of several hundred medical care standards that are hardly controversial, with common-sense items like, “Providers should reassess the alcohol intake of patients who report regular or binge drinking at the next routine health visit.” So, if the standards make universal sense, why aren’t they being followed? Unless you know of doctors who wake up vowing to harm their patients, it must be something else.

I can think of only two reasons: (a) command and control is so fragmented within our episode-based system of revolving door specialists that everyone assumes that someone else is watching the big picture, or (b) providers are too busy to do anything more than patch and mend, buried in piles of disjointed facts that are difficult to comprehend and act upon.

The authors recommend IT as the solution. Why not? No judgment is required, just analysis of discrete data elements with specific combinations of values. It’s a piece of cake compared to fly-by-wire electronics on a jet.

Sounds good, but I’m seeing red flags all over the place. Can your clinical information system or practice management application detect the following situations?

• Patients <75 years old presenting with an acute myocardial infarction who are within 12 hours of the onset of MI symptoms and who do not have contraindications to thrombolysis or revascularization
• Patients with major depression who have medical record documentation of improvement of symptoms within six weeks of starting antidepressant treatment
• Patients under age 75 with preexisting coronary disease who have an LDL level >130 mg/dl after six months of dietary cholesterol-lowering treatment

You don’t have to go far to find out. If your database person can’t do it in SQL, it probably can’t be done.

AHRQ and other groups have observed for years that we collect a lot of data, but often in unusable forms (paper, free text, or scanned documents), in scattered locations, entered too late to be actionable (diagnoses, surgical records), and with logic and structure better suited for creating bills than delivering care. Reading these standards makes that obvious. We IT folks are on the hook to solve the problem, but current systems (and use of them) are going to be a problem.

RAND was kind enough to make its standards freely downloadable as a public service at . If you’re a CIO, vendor executive, or system user, evaluate your system’s capabilities to capture and repose the necessary data elements. Then, look at how many are actually available.

How many of the standards are you managing by automation today? How many are you working to add? Think competitive advantage since it’s unlikely that this kind of scrutiny will just go away.

I maintain that most hospitals, even those using advanced clinical functions like CPOE and clinical decision support, still are missing much of the electronic data needed to make clinical decisions. While the NEJM article wasn’t written to make that observation, I think it ends up doing exactly that.

Time Capsule: Hospitals Need to Learn From Failed Transformation Missions

I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).

I wrote this piece in March 2006.

Hospitals Need to Learn From Failed Transformation Missions
By Mr. HIStalk

Michigan’s Trinity Health has put its seemingly successful $315 million clinical system implementation on hold. The announced reason: it is fine-tuning its plan to drive clinical improvements and implement evidence-based medicine.

The industry has been hard-selling “clinical transformation” for years. Hospitals repeat the mantra dutifully, although none ever seem to declare themselves transformed. Like vendors’ claims of integration, it’s always just around the corner. Post-implementation hospitals aren’t necessarily improved clinically or financially. The only predictable transformation is that hospital dollars unfailingly get transformed into vendor dollars.

Who do you blame? Surely not all vendors and hospitals are incompetent. Is clinical transformation (assuming such a thing exists) simply impossible to manage successfully? Maybe the best analogy is the space shuttle.

The space shuttle orbiter is supposedly the most complex machine ever built, despite its now-antiquated technology (there’s a parallel right there). It’s not just a flying machine – it’s an industry of pork-barrel politics, fat-cat contractors, jobs, and national pride. Somewhere in the mix might be a smidgen of science that bears little resemblance to the original promise of an inexpensive fleet self-funded through technology commercialization. (Tang, anyone?) We walked on the moon, but settled for a scientifically irrelevant low-orbit taxi.

Like the space shuttle, clinical system projects rarely unfold as optimistically planned. They require painstaking planning, unerring execution, outstanding change management, and unwavering focus. None of these are strengths of the typical health care organization. Instead of a handful of astronauts, thousands of busy employees have to be convinced to change their comfortable routine. When the going gets tough, the formerly committed VPs disappear and leave the battle to the IT techies.

Sometimes the project explodes while you watch, like Challenger or Columbia. Even when it doesn’t, interest wanes once the flashy launch is over.

If the shuttle crashed 90 percent of the time it took off, would we keep launching and irrationally hoping for success? No, we’d send the engineers back to the drawing board, or maybe even get some new engineers, or ground the program. Or, perhaps we’d just declare the whole thing undoable and settle instead for a high-value subset of the grand plan more within the scope of our capabilities.

Where hospitals are different from the space program is that we don’t learn from the industry’s widespread failures. Hospitals quietly shell out precious millions and unreasonably hope that they’ll find the success that has eluded a long string of predecessors buying the same short list of products. Reality eventually sets in, expectations are lowered, and attention moves on to something else.

Sometimes imaginary victory is declared at the HIMSS conference, proclaimed by ventriloquist vendors whose lips barely move when their customer speaks. One thing is certain: you’ll seldom hear a discouraging word from consultants, member groups, or rah-rah magazines. They make money from the illusion of mass success.

We need success stories that go beyond a glitzy lift-off. We need someone to actually be transformed, not just implemented, and for those who weren’t transformed to tell us what went wrong. The path to clinical transformation is lined with the smoking debris of earlier missions, each of them offering lessons for those willing to listen.

Time Capsule: Open Source Won’t Break Commercial Vendors’ Hold on Market, Unless…

I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).

I wrote this piece in March 2006.

Open Source Won’t Break Commercial Vendors’ Hold on Market, Unless…
By Mr. HIStalk

The California HealthCare Foundation released a report by Forrester Research last week titled Open Source Software: A Primer for Health Care Leaders. Its conclusion begins, “conditions are fertile for open source solutions to take root in health care.”

Since my open source knowledge is right up there with most CIOs and health care executives (I have next to none, in other words), I figured my populist opinions might be as useful as the next guy’s (also next to none).

I’d love to see open source take off. Physician offices, small- to mid-sized hospitals, and long term care facilities need software that’s inexpensive, easy to use, and functional. Open source promises support from talented spare bedroom programmers striving for recognition among their community instead of cash. (I don’t get that concept, but apparently it works sometimes).

The reality is, however, that open source in health care has been limited to just a few industry-agnostic, super-techie utilities that aren’t seen by end users: Apache, some Linux, a smattering of PHP and MySQL for Web pages, maybe Firefox or Netscape browsers, and a tiny sprinkling of non-Microsoft Office deployments. Maybe you’ve seen more, but I haven’t.

You’ve read a lot about the VA’s VistA, but it doesn’t fit the classic definition. It most definitely cost Uncle Sam big bucks, even if the government did later place it in the public domain. Will a thriving community improve it and support it, even starting with a finished and tested app? Maybe.

CIOs gripe loudest about Microsoft, so surely they’re jumping on free operating systems, office suites, and e-mail packages, right? Not that I’ve seen. What’s the incentive for a CIO to replace an expensive software application with a free download, an act that could end up being a career-ending move when the merry band of scattered volunteers with cool nicknames doesn’t respond to an urgent plea for help on the support forum?

Open source software ought to be cheaper because it’s free of licensing fees. However, you still have to pay those high costs for implementers, travel, hardware, middleware, and so on. If your $5 million vendor project becomes a $3 million open source project, is the savings worth the risk? For many organizations and particularly for many CIOs, I’m not so sure.

Traditional software vendors could neutralize whatever market pressure that open source brings. They could lower or eliminate licensing fees, make source code available to local developers, use more open standards and tools, and give customers a MySQL option instead of Oracle or SQL Server, all serving to bring new customers on board and work the economy of scale largely missing in our industry.

On the other hand, customers aren’t demanding that. They’re happily buying what vendors are selling, voting for the incumbent. They want people on site with them, attentive project managers, 24×7 support, and free lunches. Aggressive salesmanship and turnkey service beats geeky downloads every time.

The only chance open source has to crack the major health care application areas is if someone creates a vendor-like organization to provide support and enhancements. Customers won’t do it for themselves. Suppose a few dozen or a hundred small hospitals, a bunch of physician practices, or a trade group chipped in a few dollars each to create a shop for the further enhancement and support of an open source app? Or, if those user organizations closed ranks and gave competing vendors a take-it-or-leave-it offer for a one-time license for source code for the entire group and then hooked up with an offshore company… naaah, that’s just crazy talk.

Time Capsule: Just Back From HIMSS? Finish Implementing Yesterday’s Fads First

I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).

I wrote this piece in February 2006.

Just Back From HIMSS? Finish Implementing Yesterday’s Fads First
By Mr. HIStalk

Every HIMSS annual conference is the “Year of the Something.” CPOE, PDAs, networks, wireless, or CHINs. Newly-minted experts fill HIMSS meeting rooms with audiences of the mildly curious, the crassly opportunistic, and consultants desperate for a fresh horse to ride.

Sometimes the Something booms, although often only after several years. Sometimes it disappears without a whimper. Neither outcome dampens the enthusiasm of HIMSS, consultants, and vendors to push a new, carefully-orchestrated Something each year, likely because fewer people would attend conferences, hire consultants, and buy new products otherwise. Maybe they learned that from the car makers.

This is the Year of the RHIO. I’m not against that, but it would be nice if organizations finished implementing yesterday’s fads first, like CPOE and electronic medical records. Those are still a hopeful dream for the vast majority of hospitals. And, we know they can deliver value today.

At least some of the RHIO hype appears to be genuine (unlike the Year of the PDA, which everyone knew was a joke). It seems that technologies developed by Connecting for Health and IHE will allow RHIOs to interconnect, at least according to groups chewing through government grant money. The enthusiasm is palpable, although those with functional memories will recall that technology problems weren’t what ended the Year of the CHIN in the first place.

Eventually, RHIOs will provide patient benefit (at least three to five years from now, I expect). In the mean time, they could become CPOE redux: encouraging premature interest in immature products by unprepared organizations, consuming resources and organizational energies that could have been spent on more worthwhile projects.

Most hospitals still haven’t implemented bedside bar coding, smart IV pumps, electronic MARs, and clinical decision support, all comparatively inexpensive slam dunks compared to CPOE. But, we convinced ourselves to lead with CPOE through some bizarre logic. We’re still trying to get physicians to use it years later, passing up some great patient safety opportunities along the way.

In any case, RHIOs are about to morph from a science fair project run by grant-fueled big contractors to the mainstream. Uncle Sam is sending just one receiver downfield, and it’s RHIOs. Whether you are ready doesn’t matter. That virtually no doctors have EMRs that can contribute or use clinical data doesn’t matter. That hospital clinical systems still capture only a small percentage of electronic data doesn’t matter. What does matter is that RHIOs are hot and hospital executives will be encouraged to hop on the bandwagon.

I think many RHIOs will go right down the toilet through lack of a sustainable financing model, poor governance, or a general lack of interest in cooperating with barely tolerated competitors. Those that are successful will at least spur demand for better clinical systems in all settings. That’s good. According to several HIMSS speakers this week, we’re turning our backs on those systems just as they are becoming good enough to use.

Let’s celebrate the shockingly fast progress that’s been made on RHIOs. Clearly lots of good work has been done. But, remember that your first obligation is to ensure good outcomes for patients under your facility’s care right now. We need to finish implementing all those now-gauche technologies that didn’t make the HIMSS hot list this year.

Time Capsule: Joe Sixpack’s Concerns About Privacy and Security Need to be Taken Seriously

I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).

I wrote this piece in February 2006.

Joe Sixpack’s Concerns About Privacy and Security Need to be Taken Seriously
By Mr. HIStalk

Is it just me, or are we having a sudden epidemic of privacy and security breaches in health care organizations?

Quite a few examples have been reported in newspapers and on TV lately, including the embarrassing “backup left in the back seat” exposure at Providence Health System. Patients are angry, lawyers are salivating, and those organizations involved in such breaches are fixing the gate as the horse gallops away.

Consumer Reports joined the fray this week, expressing concern that our electronic systems may not protect personal health information. Not just from thieves, but from drug marketers and fundraisers as well (odd, I know, but that’s what they said).

Hospitals used to feel safe, rationalizing that much more attractive targets such as banks would receive hacker priority. Indeed, hacker-type security breaches that expose patient data are fortunately rare (medical information has little cash value and few willing customers, so we can’t take all the credit).

We in health care IT may believe that the biggest barrier to our obviously beneficial migration to electronic medical records is money. Outside our world, however, Joe Sixpack doesn’t give that a thought (he’s seen all those construction cranes darkening our hospital skies, so he knows we’re doing OK). He’s worried that his neighbors will learn his medical history, that his employer may fire him for poor health, or that his insurance will find a reason to deny him care because he is predisposed to need it.

Joe Sixpack understands stolen paper charts, but he doesn’t worry much about that. He knows thieves seldom bother, for the same reason they’d rather not steal pennies from a wishing well: it’s too much work and risk for too little gain. Electronic records are obviously more attractive. A single computer, backup disk, or unprotected server can hold thousands or even millions of medical records that are easy to carry and hide, attracting a thief who’s more interested in showing how smart he or she is instead of robbing a convenience store.

(And of course, there’s a good chance that the prospective thief is your own employee, as I’m sure you already know.)

Joe Sixpack might view your EMR project as unusually risky, despite liking the concept. He doesn’t know what precautions you should take, but he’ll hold you accountable if you are breached. Odd, isn’t it, that a physical break-in seldom reflects poorly on the company being victimized, but an electronic one immediately triggers outrage and disbelief?

Other industries already have electronic records, so their risk is lawsuits. Healthcare is just moving to electronic data storage, so our risk is greater. The implied threats could stall our efforts to get there.

I think we need to take quite seriously those concerns about privacy and security as we solve connectivity problems to support RHIOs and integration. That means money diverted away from much-needed functionality to hopefully never-needed security. The people sitting around the table need to come from all industries, not just healthcare. We’re fairly new at this security thing, after all.

Most of all, we need to pay new attention. When Consumer Reports is worried about health care security and privacy, that means a lot of Americans are worried. We need to reassure them that we know what we’re doing.

Time Capsule: RHIOs Are Taking Away Resources From Better Projects

I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).

I wrote this piece in February 2006.

RHIOs Are Taking Away Resources From Better Projects
By Mr. HIStalk

I’ll confess that I’m paying minimal attention to the RHIO craze. Everybody’s starting one, conferences are showcasing speakers who’ve done nothing more than announce theirs, and tiny grants are getting the whole industry atwitter. It’s like living the dot-com frenzy all over again, irrational exuberance and all.

I’m not against RHIOs, but they’re as annoying as CPOE was awhile back, taking resources away from projects that could provide more benefits to patients without the minefields.

I recently interviewed Denni McColm, an award-winning CIO of a 74-bed rural hospital no different than 80 percent of those out there. Oh, except that they’re 100 percent paperless and 100 percent CPOE, something virtually none of the celebrity CIOs and Taj Mahospitals have been able to accomplish. I’ll listen to her, thanks.

First, Denni believes that organizations should be banned from using the word “interoperability” until they can bring their own electronic information to the table. If your IT house isn’t in order, RHIOs don’t need you. Anything short of everyone contributing information equally will cause the whole concept to collapse like an imploded 1960s Las Vegas hotel, so paper jockeys need not apply.

Work instead on projects that will help your patients more than the begrudging swapping of routine lab reports with your cross-town competitor. Or, integrate all those systems you already have. Your admission ticket should be a checklist of what data elements you can supply electronically right now.

Second, Denni advocates a patient-centric RHIO model instead of the common payor-centric one. Do you like insurance companies enough to let them control patient information?

By patient-centered, I don’t mean personal health records. People are too irresponsible to reliably collect and store data with life and death importance. On the other hand, they could be given control over the trusted information generated by hospitals, physician practices, and other providers.

Suppose information resided in an Al Gore-type lockbox that contains everything from discrete electronic data to scanned documents fed over the Internet. Either the patient controls the key (similar to a password) or only they can initiate data delivery to a provider. If they don’t want you to see it, you won’t.

This model makes most privacy concerns go away. It avoids the largely unsolved problem of how you assign some sort of universally mandated patient identifier (aka “political suicide”) to sort out the throngs of people sharing the same name. The patient simply says, “send my data to Dr. Jones” and it’s done. They keep control and there’s no arbitrary “regional” service area beyond which lies a medical no-man’s land.

Maybe some RHIOs work this way. Like I said, I don’t follow them. And, if I can’t see a quick and obvious patient payoff, I probably won’t start following them any time soon. I’ve got plenty of challenges working on clinical system projects that will hopefully save lives right now.

Time Capsule: Do Technology Surveys Rate the Hammer or the House?

I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).

I wrote this piece in January 2006.

Do Technology Surveys Rate the Hammer or the House?
By Mr. HIStalk

A disclaimer: I’ve worked at three organizations that were named Most Wired. In no case did we really believe that our IT was any better than anyone else’s, but we sure bragged about our victory at every chance.

The Most Wired survey season is upon us again. Eager candidates yearn for the recognition and improved job prospects they think the award will bring. Past-winner CIOs wake up in a cold sweat after having nightmares of opening the magazine and realizing that they’ve become a Former Most Wired (e.g., loser), while their cross-town CIO competitor bags a spot on the list and waves the rag triumphantly in their face.

I’ve seen the survey encourage the same sort of rationalized fabrication usually reserved for aggressive vendors imaginatively completing RFPs. Said one of my former employees to whom I turfed off completion of the survey form, “The survey’s vague enough that it’s not really about what we’re doing, it’s about how badly you want to win.”

For others, the survey’s detailed questions invite casual answers just to get the damned thing sent off in time. Think of those annoying “qualify for a free subscription” cards that require an hour of your time just to get a worthless rag that you’ll throw out unread anyway.

As I read over the 2006 survey form, I’m encouraged that it asks some really good and meaningful questions. If they’d just spot-check some winners and expose a few frauds, I’d be behind it 100 percent. Still, it is evolving fairly well.

As I remember, the original survey measured what you have. The emphasis was on buying stuff: wireless networks and PCs, for example. The vendor sponsors of the survey aren’t exactly against that concept, and even today, the incessant message is, “Good hospitals spend a lot on IT, bad ones don’t, so which one do you want to be?”

Today’s survey is more along the lines of, “How much of the stuff that you bought gets used?” Better.

Where it hasn’t gone yet is, “Did all that stuff make you better at patient care?”

If technology is something to be admired and honored with awards, then what’s the payoff, other than getting some cool Most Wired shirts? We should see a positive correlation to improved patient outcomes, reduced costs, and a happier work force and medical staff.

Indeed, lots of glossy paper will be sacrificed after the survey trying to prove some frankly questionable premises on why “Most Wired” means “Best” (unconvincingly, if you ask me). Was information technology the cause of the improved outcomes effect, or did they simply coexist in an unrelated way?

Maybe we’re doing this wrong. The hospitals I admire are those with tiny IT departments and budgets who, nonetheless, manage to meet non-IT criteria and instead are best in patient care.

I don’t admire carpenters with cool hammers. I reserve that judgment until I see what they’ve built with them. Maybe a few of the Lesser Wired could teach us all some lessons, after which we could still buy the cool stuff if we’re really convinced it would make us better.

Time Capsule: CCHIT Should Provide More Information to Purchasers

I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).

I wrote this piece in January 2006.

CCHIT Should Provide More Information to Purchasers
By Mr. HIStalk

I admit that I paid little attention when, more than a year ago, the Certification Commission for Healthcare Information Technology (CCHIT) was born, sprung from the loins of HIMSS, AHIMA, and the group formerly known as NAHIT (now oddly and sinisterly calling itself just “ Alliance” for reasons surely less justifiable than renaming CCHIT itself, whose phonetic sounding-out always gets yuks from the watercooler crowd).

CCHIT came to life in the early, heady days of David Brailer’s rise to national prominence and, with him, an agenda that included certifying EHR products to reduce buyer risk and therefore increase adoption, particularly by that toughest nut to crack — physician offices.

I wasn’t expecting much — maybe a harmless, stuffy new bureaucracy whose core competency was hiring well-connected job seekers. Darned if CCHIT’s work groups didn’t go off and actually get some real work done that will have a significant impact on the industry.

You might mistake its 300-point evaluation tool and test scripts for a well-prepared RFP that addresses three categories: functionality, interoperability, and security and reliability. CCHIT is piloting the certification process now and will be in full certification mode by spring.

Maybe you didn’t know this: CCHIT will certify inpatient EMRs next, cranking up later this year. We aren’t talking about testing just ambulatory EMRs and interoperability. Hospital applications like those from Cerner, Epic, Eclipsys, McKesson, MEDITECH, and other full-blown inpatient EMR vendors are next.

Some vendors are complaining about the cost of certification and interference with their business. I understand their concerns, but I’ll stand by certification. Y2K Darwinism washed out weak physician system vendors, often spare bedroom programmer operations with minimal financial strength or clinical knowledge. I don’t hear much about them being fondly missed today. Vendors who don’t like CCHIT’s work would definitely be unhappy with full-blown FDA oversight similar to that of the drug and medical device industries.

CCHIT could be our industry’s Consumer Reports, just as KLAS and other companies provide our Gallup Poll. The former is an objective measure of how well products work, while the latter is a subjective assessment from customers. Put them together and you’re well on your way to a good product evaluation.

Here’s what I’d like to see CCHIT do, beyond what it has promised:

• Release the individual scoring sheets of the products it evaluates. CCHIT plans to only report whether a product has been certified. It stands to reason that some products will do better on the tests than others. Wouldn’t you like to see how well each product did? Why make new EMR adopters re-invent the wheel?
• Add a category for patient safety. We’ve seen plenty of examples in which new clinical systems harmed patients, either through product deficiencies or poor implementations. We need measurable product standards (and arguably measurable implementation standards, but that’s probably outside of CCHIT’s domain).
• Add criteria for usability. Part of the maturity of any technology is to make it intuitively and correctly usable by a wide variety of users. We expect doctors and nurses to use complex software that has confusing screens, a 500-page manual, and a two-day mandatory training session without making a mistake. Standards exist, but are rarely used by vendors or customers.

We can argue about specific criteria, but I’m looking forward to CCHIT’s results. The discussions they generate should be interesting.

Time Capsule: Is Forcing Physicians to Use Computers a Flawed Paradigm? 3/25/11

I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).

I wrote this piece in January 2006.

Is Forcing Physicians to Use Computers a Flawed Paradigm?
By Mr. HIStalk

Welcome to my weekly column, which will appear every Thursday morning as part of the Inside Healthcare Computing Electronic Update. For those subscribers who don’t know me, I’m Mr. HIStalk. I’ve been writing the blog HIStalk under that keyboard name for almost three years now, cranking out nearly 500 long and detailed articles about the health care IT industry, interviewing CEOs, and providing sniggering, sophomoric humor to an industry that often takes itself too seriously.

I don’t use my real name because I’m a cynical blowhard who likes to speak his mind. I think I’m entitled to that privilege after many years in the HIT industry as a clinician, vendor peon, informatics practitioner, and IT director for a couple of large IDNs. On the other hand, getting vendors, member organizations, and industry notables riled up (especially those associated with the hospital from which my paycheck flows) is hardly a ticket to job security. So, let’s just leave it as Mr. HIStalk, if that’s OK with you. I still need that day job.

My writing here will be specific to one timely topic, different than the highly-condensed news and occasional editorial that I write for HIStalk. I have just one objective: to make you think. Like an aging hippie, I’m imploring you to question authority and don’t trust people who tell you what to believe (even me).

Let’s jump into what’s new. The online world has been abuzz about the Children’s Hospital of Pittsburgh article in the December issue of the journal Pediatrics, which suggests CPOE caused increased mortality in the hospital. I’ve put some of my thoughts about this on HIStalk, but let’s look at this story from another angle. Namely, is the paradigm of forcing physicians to use our computer systems personally and directly a flawed one?

Think of your most recent meeting with a local banker, attorney, real estate agent, dentist, or accountant. Did they place a computer monitor between themselves and you, making your conversation nearly inaudible over their furious keyboard tapping? Did you trust their advice even though they weren’t staring at the computer screen while awaiting an infusion of wisdom from faceless offshore programmers whom they’ll never meet personally? Did you think less of them because they listened and talked instead of typed?

I haven’t seen that. So why then do we expect doctors to be held to a different standard? It doesn’t make much sense, especially considering that they’re mostly self-employed and are as much a hospital customer as patients. Is it realistic to believe that their profession alone requires them to interact constantly with a computer to be effective, both providing information for use by others and receiving similar information in return?

Suppose you go into a restaurant and the waiter informs you that a new policy requires you to enter your order directly into a PDA, which will also provide recommendations and dietary warnings that someone has decided you should be forced to review. This will also solve the problem of illegible food orders and wastage due to poor waiter handwriting, along with incorrect tallying of your final bill (and maybe slyly pitching high-margin alcohol and desserts along the way). Maybe you’d see this as a good thing, maybe not. And if not, you’d go elsewhere.

As a customer, the only place that I see a lot of computers in use is in retail establishments, where the user is the lowest level of employee. Those folks aren’t rocket scientists. They didn’t have to go away for a week of training, nor do they have to tape reminders to their smocks or juggle 10 passwords. The systems they use were written with them in mind: simplified, optimized to their workflow, and nearly impossible to mess up. The part-time kid at McDonald’s can get your hamburger order right just as easily at Wendy’s, every time. Very smart minds dumbed down the systems to be as foolproof as the French fry cooker.

CPOE systems, on the other hand, are confusing, even to long-time users who have attended training. Just ask a nurse or pharmacist exactly what will happen when they change the schedule of a QID order and you’ll see what I mean. Hospitals that found their clinical systems too inconvenient for impatient nurses to use (turfing them off to unit secretaries) are now surprised at CPOE pushback from the docs. If their systems are so great, how come every nurse doesn’t already use them for medication barcoding, for entering nurses’ notes, for receiving point-of-care recommendations, and for shift scheduling based on expertise?

I’m not saying that CPOE is a bad concept. I’m saying that CPOE systems (and user implementations of them) need to be better to avoid harming patients, as the Pediatrics article’s authors described in Pittsburgh. If not, then please don’t install anything that makes the situation worse. And if those systems really do reduce unwanted outcomes and decrease costs as everyone believes (but few have proven), shouldn’t whoever benefits from that situation be willing to pay doctors for the indisputable extra time it takes to use the systems, possibly in the form of reduced malpractice insurance premiums or higher reimbursement?

Maybe what we should be pitching is electronic medical records — still a new concept to the hospitals that are chasing the sultry siren of CPOE instead of automating the basics first. Let’s worry less about who does the keyboarding and concentrate instead on making all existing information available in electronic form.

In the meantime, vendors can do a better job in designing CPOE that works for doctors, not programmers. And we in hospitals can rethink whether we’re using doctors optimally by having them interact with computers, doing the same things they did on paper, or whether new roles are needed for “information assistants.”