Harvard Says Computers Don't Save Hospitals Money 398
Posted
by
kdawson
from the always-jam-tomorrow dept.
from the always-jam-tomorrow dept.
Lucas123 writes "Researchers at Harvard Medical School pored over survey data from more than 4,000 'wired' hospitals and determined that computerization of those facilities not only didn't save them a dime, but the technology didn't improve administrative efficiency either. The study also showed most of the IT systems were aimed at improving efficiency for hospital management — not doctors, nurses, and medical technicians. 'For 45 years or so, people have been claiming computers are going to save vast amounts of money and that the payoff was just around the corner. So the first thing we need to do is stop claiming things there's no evidence for. It's based on vaporware and [hasn't been] shown to exist or shown to be true,' said Dr. David Himmelstein, the study's lead author."
Don't just computerize the process (Score:5, Insightful)
Don't just computerize a process (or blindly apply technology to replicate an existing process) and expect to see savings.
Well (Score:5, Insightful)
Here's a relevant quote from "Superfreakonomics" :
The diagnosis was clear: the WHC emergency department had a severe case of "datapenia," or low data counts. (Feied invented this word as well, stealing the suffix from "leucopenia," or low white-blood-cell counts.) Doctors were spending about 60 percent of their time on "information management," and only 15 percent on direct patient care. This was a sickening ratio. "Emergency medicine is a specialty defined not by an organ of the body or by an age group but by time," says Mark Smith. "It's about what you do in the first sixty minutes."
Smith and Feied discovered more than three hundred data sources in the hospital that didn't talk to one another, including a mainframe system, handwritten notes, scanned images, lab results, streaming video from cardiac angiograms, and an infection-control tracking system that lived on one person's computer on an Excel spreadsheet. "And if she went on vacation, God help you if you're trying to track a TB outbreak," says Feied.
To give the ER doctors and nurses what they really needed, a computer system had to be built from the ground up. It had to be encyclopedic (one missing piece of key data would defeat the purpose); it had to be muscular (a single MRI, for instance, ate up a massive amount of data capacity); and it had to be flexible (a system that couldn't incorporate any data from any department in any hospital in the past, present, or future was useless).
It also had to be really, really fast. Not only because slowness kills in an ER but because, as Feied had learned from the scientific literature, a person using a computer experiences "cognitive drift" if more than one second elapses between clicking the mouse and seeing new data on the screen. If ten seconds pass, the person's mind is somewhere else entirely. That's how medical errors are made.
END QUOTE
I agree wholeheatedly with the last bit : I can't count how many times I've been to a doctors office or library or other institution and had to wait for a person to pull up my information on "the system". If you're gonna build a friggin computer system to handle local records, for the love of God don't scrimp on the hardware! Optimize the software! It should be INSTANTANEOUSLY fast!
I would also guess... (Score:2, Insightful)
That some of this has to do with the staff being largely of the 35+ crowd and the propensity of that crowd to not know how to use computers even remotely as well as, say, a 16 year old kid does right now.
Computers take more work to use when you don't have a nice grasp on not only the software or function you're doing, but the regular logical deductions you make from repeated observation and experience.
From my experience in life, most older people have somehow adapted themselves to 'get by' with technology, but without actually knowing what is really going on. Many will think the monitor is the computer. Many have no idea what the basic components are. And, hell, many are even clueless at the overly-simplified layouts of hardware nowadays with color coding and the square-peg-square-hole approach to basically everything.
Make the majority of a staff fill this description and you can be damned sure plenty of time is being spent moving the mouse around cautiously while looking down the nose in deep confusion and wonder.
question: is a hotkey actually hot? which one is it?
no shit (Score:5, Insightful)
Almost everyone who's ever used a line of business app could have told you this. Good LOB apps will ask the question "how can we use PC to make the experience more efficient?". Bad ones will just say "paper sucks, lets make it digital!" have the exact same fields a paper would have, but make you type it. The bad ones might be marginally easier for management because of their rudimentary search and reporting, but are usually no different or even worse for the actual day to day users.
Yet management is continually suckered into thinking less paper == more efficient, and there are _a lot_ of bad LOB apps out there because of it.
Of course... (Score:4, Insightful)
If you hand a bunch of Luddites a computer system they will tell you it isn't saving them any time.
The system has to meet the needs of the users.
The users have to want to use the system.
If you don't meet both of these requirements it will fail.
Re:Well (Score:3, Insightful)
...But it has to look pretty, or the folks with access to the bank account will never buy it! It also needs animated sliding panels, customizable positions for all controls, and must fit the graphical style of Windows 7, so the office staff don't get confused. When the programmers are done with those important goals, then they can work on the petty stuff like speed and usability.
Let's not forget, it also absolutely MUST interface with the mainframe they kept records on in the 80's, just in case they need that information (but there's no budget for migration), and according to the boss's nephew who "knows computers", the next big thing will be X, whatever that is, so the system must use X, to do whatever it is that X does.
Re:I would also guess... (Score:4, Insightful)
> That some of this has to do with the staff being largely of the 35+ crowd and the propensity of that crowd to not know how to use computers even remotely as well as, say, a 16 year old kid does right now.
That used to be a favorite argument to explain away poor clinical system adoption. But it does not hold true anymore. An average doctor today is at least as computer savvy as an average teenager. They may not use SMS, twitter or use facebook as much as the teens, but they certainly know how a computer works. This isn't the 90s when computers were optional in life.
> Computers take more work to use when you don't have a nice grasp on not only the software or function you're doing, but the regular logical deductions you make from repeated observation and experience.
Good clinical software should not need you to be an expert in computers... just that software... the one they use for several hours each day. And if it takes considerable experience to get up to speed... that's a usability problem... not a user problem.
Designed for Entrepreneurs (Score:5, Insightful)
Computerized health care systems are not designed for the benefit of hospitals. They are designed for the benefit of entrepreneurs.
Health care is a multi-bazillion dollar industry where information is managed via bearskins and stone knives. Development of an integrated computerized health care system will net the intelligent investor more money than even Microsoft can dream about.
This is the message that people I will call "serial entrepreneurs" pitch. Their intent is not to build such a system (that would be nigh on impossible given the absolute chaos of incompatible processes that currently exist in hospitals). They simply want to build a system that looks close enough that stupid investors will throw millions of dollars at it. The potential payoff is so big (seemingly) that people will keep throwing money at it even after said entrepreneurs have razed and burned a stack of companies.
Of course, eventually there *will* be a company that succeeds (mostly by accident). That company will run suspiciously like SAP where there will be a very complex set of computer programs designed to support an even more complex set of processes. These processes in turn will have nothing to do with the underlying business of providing health care. However senior management will be ecstatic that they finally have a unifying computer based process, and the only people who fully realize its true futility will be the people doing the work. They, of course, will be ignored.
Let me explain... (Score:5, Insightful)
You: Computers have made my life much easier.
Harvard study: Computers don't save hospitals money.
Note the slight difference there?
Re:Well (Score:5, Insightful)
I made a call to HP (abbreviated to protect the company :) recently to have a failed disk replaced under warranty. I went to great lengths to explain that I was a consultant acting on behalf of the customer, gave HP all of my details and all of the customers details etc. I could hear constant typing in the background so something was being entered somewhere. About 20 minutes later I got a call from my office saying they had HP on the line asking who the onsite contact was, who the customer was, and where the part should be sent.
It's not just hospitals... I think I can generalise the conclusion of the article - if the solution (IT or otherwise) isn't designed/built right, and people don't know how to use it right, then it isn't going to work right and is going to make peoples lives harder not eaiser. Seems kind of obvious when you put it that way though.
Parkinson's laws (Score:5, Insightful)
The boundless creativity of politicians and bureaucrats to develop new and more complex regulation is bounded only by the bureaucracy's inability to implement them. The absolute size of the bureaucracy is constrained by external factors, so the only effect of automation can be to increase bureaucratic complexity.
Parkinson's laws are as valid and insightful as always. If someone by chance have missed them, here they are:
Parkinson's First Law:
Work expands or contracts in order to fill the time available.
Parkinson's Second Law:
Expenditures rise to meet income.
Parkinson's Third Law:
Expansion means complexity; and complexity decay.
Parkinson's Fourth Law:
The number of people in any working group tends to increase regardless of the amount of work to be done.
Parkinson's Fifth Law:
If there is a way to delay an important decision the good bureaucracy, public or private, will find it.
Parkinson's Law of Delay:
Delay is the deadliest form of denial.
Parkinson's Law of Triviality:
The time spent in a meeting on an item is inversely proportional to its value (up to a limit).
Parkinson's Law of 1,000:
An enterprise employing more than 1,000 people becomes a self-perpetuating empire, creating so much internal work that it no longer needs any contact with the outside world.
Parkinson's Coefficient of Inefficiency:
The size of a committee or other decision-making body grows at which it becomes completely inefficient.
Re:Let me explain... (Score:5, Insightful)
>You: Computers have made my life much easier.
>Harvard study: Computers don't save hospitals money.
>Note the slight difference there?
yes - but you missed the bit about efficiency. "Computers have made my life much easier." is usually how we express efficiency.
Over a decade ago I did a stint at a hospital looking after the pathology database. When it was down and paper records were required then lives were at risk due to the lack of efficiency (time spent accessing paper). It honestly scared me!
I'm sure things are much much more reliant on computers now. Computers are not just for the hospital admins.
Re:Transferability (Score:5, Insightful)
That's only part of the story. A LOT of systems are put in by heads of medical departments who engage directly with vendors, who tell them this system will cure all their ills and make the world a better place.
They then buy in this system without asking anybody, and turn up at IT saying "We've bought this, put it in now please". Most hospital directorates back the clinicians (politics, gotta love it) and force IT to support this, even though it may duplicate information held elsewhere, or not be able to communicate with anything else. This crucifies efforts to create an enterprise class architecture.
That being said, there are (in the NHS) many moves towards having everything standardised and digital (PACS, for example, works nicely; Dicom imagery across all hospitals connected to the NHS network. That's your XRay and MRI imagery right there).
The problem is that very few places take IT seriously. It's viewed as a "wave a magic wand and things happen" discipline. Few want to hire system admins, let alone systems architects.
And without people to actually work at integrating IT to the business, and without them having the remit to be able to affect business processes to help this symbiotic relationship take hold, then places will continue to scrabble ineffectually.
If you're building a house, hire an architect. If you're building an IT system to prop up your business correctly, hire a systems architect.
You could, of course, be happy with your IT system being the logical equivalent of a house built on mud with 22 windows on one side of it (never facing the sun) and no stairs to the upper floor that can be used.. But hey. You choose the path you walk.
Variables... (Score:3, Insightful)
There are too many variables...
Computers installed and maintained in a competent fashion, running software which is appropriate to the job at hand and being used by staff who are proficient with that software can save money, potentially a lot of it...
On the other hand, many IT projects are terribly mismanaged, poorly budgeted, installed by cheap unqualified staff, running unsuitable software which expects people to adapt to its way of doing things rather than the other way round, and used by staff who are unsure how to use the system correctly and are often too fearful to touch it unless forced to..
Ask the average joe on the street, and they will tell you that computers are extremely unreliable black boxes, they have no idea how they work and are very fearful of touching them incase they break, especially at work where they're likely to face disciplinary action for breaking the computers.
In a lot of cases, computers are simply not appropriate, and in many more cases computers in the form that get installed are completely unsuitable for the task and are actually inferior to what they replaced.
You also have the attitude of third party suppliers and corrupt people high up in the client organizations where the situation changes from "what do we need" to "how can we justify purchasing something from "... IT is one of the worst affected industries for this, because people generally have less understanding and are therefore easier to fool.
The goals of these people is not to save money, it's not their money to save, it's someone else's money that they are in charge of, and their primary goal is to siphon as much of it out and into their own pockets as possible.
possible reasons why (Score:3, Insightful)
Re:Transferability (Score:4, Insightful)
There are clear benefits of the new system so I am confident to say that not only is it more efficient and will save money compared to a manual system, but it will also do the same compared to our other two clinic management packages - one is old and reliable (accessed through VT220 terminals or PCs running an emulation package) but very outdated and has no serious reporting or connectivity abilities, the other is 'modern' but buggy (crashes often), poorly written with a bad database schema that is totally space inefficient.
I encounter situations like this a LOT... There will be an old system which is perfectly reliable, has been running for years and everyone can access it using whatever ancient terminals they have at their disposal. And it will usually be quite efficiently written because it runs on old hardware.
Then some vendor will come along and blind management with a pretty graphical frontend, so they sign up and begin a transition to a new fancy looking graphical system which looked very pretty to the management types who quickly demoed it at the vendors offices...
Of course, the vendors setup will have a very small data set, will be carefully set up to look as good as it can (they might not even let you touch it, just demo it themselves being very careful to avoid features which are known to be buggy), and the management types won't have tested it for very long (or at all) before they decided to buy, and these same management types won't have to use the resulting system once it's installed.
Costs will rapidly escalate as you have to replace all your ancient terminals with new fancy equipment designed to handle the pretty graphics...
You start loading your live data into the new system and find that when it has actual data in it, the new system is very slow and inefficient (but still looks nice!) because it was never tested under any realistic usage cases...
You find that the original quoted hardware requirement was already insufficient (to make it look cheaper), and coupled with how slow the new system runs with real data you now have to increase your hardware budget...
And once the system is finally installed and people start using it, you find that...
While the app looks very pretty to management types, the people who actually have to use it find that the pretty graphics get in the way, and that the new app is far less usable than the old one.
Your users were used to the old system, and don't like the new one, but this gets dismissed as "users dont like change" and blamed on them wether that's the case or not.
Even new users who weren't used to the old system have trouble with the new one..
When under actual load, the performance issues are even worse..
The new system has lots of bugs, which the vendor expects you to adjust your working practice around rather than bothering to fix them...
The new system also has a different workflow, which again the vendor expects you to adjust your working practice around.
The new system brings with it a lot of unnecessary functionality which you don't need, and which will get abused by staff and external hackers alike (people didn't spend all day using facebook on green screen terminals, and didn't browse websites or view files which try to exploit your machine and own it)..
As a result of the unnecessary functionality and new security risks, your administrative burden is now much higher (or the vendor convinces you otherwise, and you coast along for a while before you start having major problems).
There's a lot to be said for keeping it simple!
Re:Transferability (Score:2, Insightful)
The conservatism in the medical sector is so extreme, that even when a new technology appears, the old technology is *still* retained, usually for legal purposes. An example from my hospital for instance, it used to be that blood results would arrive in small pieces of paper that a secretary would affix to a special page with in-built stickers on the back of the patient's notes, and the doctor would inspect and sign it there. Other than calling the lab in very urgent cases, that was the only system to check bloods, so the reports were delivered asap. Now the blood results are computerised instead, meaning you can look them up on a screen rather than wait for a secretary to affix them to patient notes when the reports arrive. As a result, the delivery of the paper reports is less urgent and takes days. However, the doctors are now responsible to MANUALLY COPY all results from the computer screen, into a page on the back of the notes, which can take several minutes. Then the old-style paper reports *still* arrive, and the doctors have to spend several minutes again signing them to prove that they have been inspected (even though they have already manually copied them in the notes as well). This is done for both legal reasons, and the pretext that the bloods need to be available in time for the ward round in the patient's notes. (ironically, a mobile workstation is used to view the Xrays through PACS though.)
I don't really blame doctors and nurses that much then, when they appear resistant to new technologies, because in the short term, they're introduced so clumsily that they only cause trouble, and their design isn't always ideal to predict if it will be worth it in the long term. I remember I did a project on the state of computerization of the NHS, and I came across doctors who were adamant computers should be banned from the workplace; except, apparently for "the dot-matrix printers which produce sticky labels with the patient's names on them. Those are a lifesaver!" (sigh)
The other reason, of course, is that, due to litigation on one hand, and blatant lack of clearly defined job responsibilities on the other, people adopt a 'it's not in my job description' attitude, and require formal training for every minor thing they do. Nurses in my hospital for instance only administer a drug if it's on their training list; any other drug they call a doctor (not that I've had training in administering that drug, but I'm the scapegoat; the patient needs the drug and I'm the last person in the chain.) This attitude makes it particularly difficult to introduce anything new in the workplace, and even such ridiculously "for-justification-purposes-only" training sessions, cost a lot time and money to a trust.
I am one of those rare breeds of doctors that have briefly gone into computing, in the hope of returning to the NHS and making a difference from the clinician's (rather than manager's) point of view. Alas, I now realise changes are more about politics than about actual progress. There is in fact a wealth of innovative ideas within the clinician collective, which will never see the light of day because applying them would involve inconveniencing certain vociferous individuals for a short period of time.
Re:Transferability (Score:5, Insightful)
I have a masters in business. When the people making the business decisions are divorced from the operations of the business, the item that helps them most may not help the company at all. Having seen the results of such decisions, I assure you the consequences are quite real, and because of poor managerial decisions.
My experience in medical information mgt ... (Score:4, Insightful)
Re:Transferability (Score:4, Insightful)
Re:Transferability (Score:4, Insightful)
Wow, I so just NEVER post anonymously but... I work at a healthcare company. Specifically, a Healthcare IT company. A very big one. One which develops an elctronic medical record, amongst other things, and is joined at the hip by several hospitals (we are a non-profit, they founded us)...
Think about the flaws in how the government works, and you can start to grasp the problem. These institutions are setup, not to make a profit, but to do a job. To that end, they are going to do that job... come hell or high water. Its noble, its great, its a bureaucratic wet dream. They even budget the same way. In fact, last year is the FIRST TIME IN MY CAREER that when the end of the fiscal year rolled around, we did NOT hear talk of needing to use up the rest of our budget before we lose it.
The problem is, that they create a whole bunch of fiefdoms, give them a mission, and then let them just creep that mission over the years. New servers, new disaster recovery plans. More security.
Then we interact with government, and everyone has a stake in healthcare so...more regulations? Ever heard of hippa? No? Then you don't work in healthcare. We have yearly ethics classes, a whole department whose job is to police ethics internally. Increasing regulations seem to push us forward a lot.
We are a mini-government. In many ways, I like it. How many other workplaces have an appeals process on disciplinary that can go all the way to an employee review board of randomly selected employees from other departments? We essentially have a jury system built into the company!
And while governments have a feedback loop through voting, we do too. We have the board, which is chaired by big wig stakeholders, many of whom are hospital administrators and power player doctors. They allocate our budgets, they push agendas... which feed through us, and back to the hospitals, and their management.... which is our feedback loop.
Its a labyrinth of departments, groups, teams, on down the line. An undulating stack of bureaucrats each moving forward, increasing his scope. Every department knows money is being wasted. However, its the other guy wasting it, because we are on a mission. We have to deliver this service right here, no matter what it costs.
I wish I had time for more but, my group has a mission. Maybe later I can wax poetic about how "middle heavy" institutions like this grow. Remember those articles on the Gervais principal and how it relates to "The Office". Google it and reread it... realize that these organizations work under those dynamics, but remove the "organization falls apart" feedback loop. Imagine that model running its course for the 150 years that some hospitals have been around.
Of course, theres been corruption too. We grumble about not even being able to take pens or free classes from vendors anymore. A whole host of new policies, all because a couple of guys were scamming contracts. These policies will never go away... only grow. (something which I have seen at 2 of the places that I have worked. In one they were fresh policies from a scandal that happened while I was there, and one from a scandal 20 years prior)
THAT is where the problem is. This constant slow creep of policies, regulations, departments.
Re:Transferability (Score:3, Insightful)
Sorry I am going to disagree here...
The problem with the IT industry is that it does not solve problems for users. Programmers for the most part have very little domain knowledge, and it shows. About 5 years ago I saw the trend of shifting from general knowledge to specific and shifted to the investment banking industry.
You might oh you f***d up big time. Ha, on the contrary. I actually got in at the right time. They are now looking for people who can write code and trade. Not an easy combination, but something I acquired and it has paid off handsomely.
Open source and closed source has plenty of examples of people who know tech, but know squat in the domain. Once at a speakers table I even had one speaker tell me, "oh you can learn a domain in about 8 weeks." Really? Yeah RIGHT!
When you say, "If you're building a house, hire an architect" I would disagree. I would argue hire a local contractor who has built a few dozen homes. For an architect will cost too much for what its worth. Of course if you are a billionaire, then by all means hire one. Or if you are building something unique, by all means. Otherwise hiring an architect will cause you to overpay and under deliver.
Re:The key being ... (Score:3, Insightful)
I do IT for a major regional hospital chain, and all this time, I thought it was just my company that was this fucked up.
What you're talking about is EXACTLY what happens. Doctors, managers, vendors, whoever CONSTANTLY show up with junk hardware and software, throw it at us, and expect us to support it. The organization is so bloated around the middle that no one has the authority to tell anyone else no. We have hundreds of Access databases, SQL servers running on people's desktops, and apps that we've never heard of turning up constantly.
And it all happens so fast, and we're SO understaffed (4 IT staff for 2000+ devices in my hospital) that we don't have a prayer of keeping track of it all.
And the understaffing is a problem in and of itself. The organization as a whole has around 30K total employees, of which 700 are IT staff. Probably 10% of the IT staff does next to nothing. Another 30% does nothing beneficial to patient care, or actively makes patient care harder. 20% are redundant management. For example: my particular part of the company, staffed by 4 IT grunts such as myself, has 4 managers directly over me: 1 team lead, 2 Project Managers, and an Account Executive. All of whom often want conflicting things done at the same time. Finally, the last 50% of IT here is made up of everybody else working their asses off to make up for the rest of the crap.
No wonder heatlh care costs are sky-high. IT is indicative of the whole mess... the company is a gigantic mish-mash of hacks thrown together at the last minute to satisfy the newest bureaucratic requirement, public opinion, expensive doctor, negative news story, malpractice suit, or demands from the board or rich donors. There's no way anything like this could run efficiently.
Re:Parkinson's laws (Score:4, Insightful)
For some large government projects, it gets to the point that it would be cheaper to simply hire 10 different companies to all produce the software product that you wanted, and then simply pick the best one.
Bingo. You have just pointed out why capitalism beats socialism. Nine private companies fail, one emerges as the industry leader.
Re:Transferability (Score:3, Insightful)
The systems aren't put in help the doctors. (...). But that's not what the systems are. They should start working now to have all records be electronic, X-rays, MRIs, personal history, etc. should be in formats that can be directly shared between doctors.
I'm going to argue just a bit. My wife just went through breast cancer this summer. The records, MRIs and actions that took place -were- electronic, and at more than one point -were- used to facilitate actions between a group of physicians that were part of her care. Meds were ordered electronically, and the new records generated from the process are all electronic. She had MRI's taken across town, and the pics were sent in electronic form to her surgeon and oncologist, who conferred via something like Net Meeting on them (don't know if it was net meeting or what, just that they had a con call and viewed the films together). One of the challenges that was presented was that she had old records from a prior incidence of cancer ten years ago, which are all still on paper/fiche. These had to get pulled and sent via courier. Overall, the experience that we had was highly electronic, and by and large was pretty efficient.
I won't dispute that a large amount of the systems are oriented towards capturing billing information. This is necessary because of the US's insistence on individual insurance plans, so for every action, someone has to get billed, which means a record has to be made of the actions. I think these systems still arguably help patient care, because they do still aid the physician and nurses in capturing the information, which would likely be slower if they had to use paper. I think it's a flaw to criticize hospital administrators for designing/using these systems, though. The hospitals are just following the mandate of the compensation system that they work under in the US.
Re:Parkinson's laws (Score:3, Insightful)
Bingo. You have just pointed out why capitalism beats socialism. Nine private companies fail, one emerges as the industry leader.
Then the industry leader becomes so large it steamrolls competition while at the same time producing flabby, uninspired software. This bloated behemoth will persist long past when it should have mercifully died in its sleep and it takes ages for incompetence to erode that market lead, to allow competitors back into the marketplace. And when you think it might finally take in that final breath, the capitalists running the thing will successfully lobby the government for a bailout, not even blinking as they suck the government welfare teat. But you can bet they'll look down on poor people who might do the same.