Harvard Study: Computers don't save hospitals money.
December 1, 2009 9:40 AM Subscribe
Harvard Study: Computers don't save hospitals money. An article from Computerworld cites a clinical research study in the American Journal of Medicine. Four years of research finds that "the immense cost of installing and running hospital IT systems is greater than any expected cost savings." (Also on Wired and Slashdot.)
“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,” he said. “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.”
“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,” he said. “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.”
From the Wired article:
...only a handful of hospitals and clinics realized even modest savings and increased efficiency — and those hospitals custom-built their systems after computer system architects conducted months of research.
See, that right there, that's what makes me question the veracity of this. Usually, when I hear arguments in favor of large-scale computerization of hospital records, the primary reasoning is to enable easy transfer of medical data between facilities, which means not "everybody builds a really expensive custom solution" but "sensible standards are agreed upon for data exchange." Also, custom work is likely to be a great deal more expensive than a reasonable mostly-turnkey solution; hospitals are (mostly) not special snowflakes, and reinventing the wheel is really expensive.
posted by Tomorrowful at 9:48 AM on December 1, 2009 [17 favorites]
...only a handful of hospitals and clinics realized even modest savings and increased efficiency — and those hospitals custom-built their systems after computer system architects conducted months of research.
See, that right there, that's what makes me question the veracity of this. Usually, when I hear arguments in favor of large-scale computerization of hospital records, the primary reasoning is to enable easy transfer of medical data between facilities, which means not "everybody builds a really expensive custom solution" but "sensible standards are agreed upon for data exchange." Also, custom work is likely to be a great deal more expensive than a reasonable mostly-turnkey solution; hospitals are (mostly) not special snowflakes, and reinventing the wheel is really expensive.
posted by Tomorrowful at 9:48 AM on December 1, 2009 [17 favorites]
On the other hand, the study also says "More encouragingly, greater use of information technology was associated with a consistent though small increase in quality scores." (Quality of health care, that is).
posted by Nelson at 9:49 AM on December 1, 2009 [3 favorites]
posted by Nelson at 9:49 AM on December 1, 2009 [3 favorites]
Computerized medical records will also help the NSA find those sneaky terrorists.
posted by Joe Beese at 9:52 AM on December 1, 2009 [1 favorite]
posted by Joe Beese at 9:52 AM on December 1, 2009 [1 favorite]
Along the lines of what crayz said, in my limited experience the two biggest limitations to using computers effectively at at my work are 1) users are frequently not well versed or comfortable with technology and 2) we have a lot of homegrown applications that work in weird ways and don't play well with commercial software.
posted by ghharr at 9:55 AM on December 1, 2009
posted by ghharr at 9:55 AM on December 1, 2009
From most of what I've seen of internal corporate IT, the reason computers don't save money is that 95% of internally developed software is just absolute garbage
I would argue that a lot of the custom solutions sold to corporations are also absolute garbage. Developers know all they need to do is make something that gets the job done. Doing it well, easily or efficiently is not a real concern, because the people buying the "solutions" often don't care about such things, and are unaffected by most of the usability flaws that drive employees to frustration.
posted by bugmuncher at 9:55 AM on December 1, 2009 [5 favorites]
I would argue that a lot of the custom solutions sold to corporations are also absolute garbage. Developers know all they need to do is make something that gets the job done. Doing it well, easily or efficiently is not a real concern, because the people buying the "solutions" often don't care about such things, and are unaffected by most of the usability flaws that drive employees to frustration.
posted by bugmuncher at 9:55 AM on December 1, 2009 [5 favorites]
I should note that "veracity" was a poor word choice, but I lack the statistical vocabulary to correctly say "I'm sure the data's solid, but I question the interpretation of the results."
posted by Tomorrowful at 9:55 AM on December 1, 2009
posted by Tomorrowful at 9:55 AM on December 1, 2009
From the article:
The problem "is mainly that computer systems are built for the accountants and managers and not built to help doctors, nurses and patients," the report's lead author, Dr. David Himmelstein, said in an interview with Computerworld.
No, computers won't make your broken arm heal faster. But they will make your bill show up faster and more efficiently.
In other words, there areefficiency gains. But the money saved from those gains aren't plowed back into making other parts of the system work better. It just goes into someone's pocket.
IMO, this is another example that simple gouging is the big unspoken driver of spiraling health care costs. Health care costs more because health care providers are charging more. Period.
posted by Cool Papa Bell at 9:55 AM on December 1, 2009 [8 favorites]
The problem "is mainly that computer systems are built for the accountants and managers and not built to help doctors, nurses and patients," the report's lead author, Dr. David Himmelstein, said in an interview with Computerworld.
No, computers won't make your broken arm heal faster. But they will make your bill show up faster and more efficiently.
In other words, there areefficiency gains. But the money saved from those gains aren't plowed back into making other parts of the system work better. It just goes into someone's pocket.
IMO, this is another example that simple gouging is the big unspoken driver of spiraling health care costs. Health care costs more because health care providers are charging more. Period.
posted by Cool Papa Bell at 9:55 AM on December 1, 2009 [8 favorites]
Isn't it possible that a market for a universal platform will come into existence?
posted by jefficator at 9:58 AM on December 1, 2009
posted by jefficator at 9:58 AM on December 1, 2009
Nurses are very intelligent and technically minded people... and they're made to feel like helpless idiots by the programs they're expected to use. A note on a paper chart that takes three seconds is now five solid minutes of hunting through menu options, screens, and mandatory text fields. My mom showed me the system her hospital installed last year, and I was in shock. What a stupid, stupid way to waste your employee's time. I'm not talking about the stuff required to make sure the patient gets the right meds and their privacy isn't compromised... I'm talking about struggling with a massively bone-headed application written by someone who had no interest in talking to an end-user, ever.
The utter contempt of medical software for UI is unbelievable, and probably costing hospitals and doctor offices millions in lost productivity.
posted by Slap*Happy at 9:58 AM on December 1, 2009 [19 favorites]
The utter contempt of medical software for UI is unbelievable, and probably costing hospitals and doctor offices millions in lost productivity.
posted by Slap*Happy at 9:58 AM on December 1, 2009 [19 favorites]
The past 50 years or so of corporate IT (I've been there for better than 1/2 of that) have shown that if you don't change the way you do things, computers will only make things more complicated and expensive. At the risk of sounding like a Socialist, basically what TOMORROWFUL said -- create a standardized system that everybody adheres to and things will get better. Hire expensive consultants because "what we do is different" and you are pissing money into a bottomless pit
posted by ElvisJesus at 10:00 AM on December 1, 2009 [4 favorites]
posted by ElvisJesus at 10:00 AM on December 1, 2009 [4 favorites]
Isn't it possible that a market for a universal platform will come into existence?
Its already there. Corporate culture refuses to go thnat route.
posted by ElvisJesus at 10:02 AM on December 1, 2009
Its already there. Corporate culture refuses to go thnat route.
posted by ElvisJesus at 10:02 AM on December 1, 2009
My mom's an RN. The thing is, sure, they're using computers, but they're also, for some reason or another (I think mostly in case the computer fucks up, which is likely, or something vitally important is keyed in wrong, which is even more likely) doing even more paperwork.
posted by Sys Rq at 10:02 AM on December 1, 2009 [1 favorite]
posted by Sys Rq at 10:02 AM on December 1, 2009 [1 favorite]
No, computers won't make your broken arm heal faster. But they will make your bill show up faster and more efficiently.
Computer automation also documents your health history, which makes it easier for insurance companies to generate excuses to deny claims.
posted by Blazecock Pileon at 10:03 AM on December 1, 2009 [1 favorite]
Computer automation also documents your health history, which makes it easier for insurance companies to generate excuses to deny claims.
posted by Blazecock Pileon at 10:03 AM on December 1, 2009 [1 favorite]
It's all about software. Large organizations are notorious for not picking good software, not deploying it correctly, etc. I can't imagine that hospitals would be any different. Like what Slap*Happy said, terribly designed software kills all benefits you would get from computerizing records.
posted by demiurge at 10:04 AM on December 1, 2009
posted by demiurge at 10:04 AM on December 1, 2009
I'm a PC, and I value the fact that I can pop online and find user-generated solutions to most of my needs, usually with the requisite time spent sorting through buggy clunkers, or at least have my pick of competing software to pay for. It's a delightful and messy democratic/free market way to do personal computing, and I prefer it to Apples sleek monoculture (as much as I love and applaud programs like garageband).
I'm not sure PC is the way to do medical computing, though. We regulate almost everything that goes on in the healthcare industry on the state and federal level. We're in the process of pushing that control further with Obamacare, which includes incentives and goals for more digital healthcare.
I'd suggest that a single operating system and set of tools be set at the ground level, with continued compatibility and openness as core principles. It'd be a big project, it would constrict some freedoms, and it would have to be done by people with far more tech savvy and foresight than myself, but it seems to me that medical computing will devolve into a cluttered mess if not done the *sigh* Apple way.
(I realize I may be oversimplifying this ridiculously; I am a bit out of my depth)
posted by es_de_bah at 10:04 AM on December 1, 2009 [1 favorite]
I'm not sure PC is the way to do medical computing, though. We regulate almost everything that goes on in the healthcare industry on the state and federal level. We're in the process of pushing that control further with Obamacare, which includes incentives and goals for more digital healthcare.
I'd suggest that a single operating system and set of tools be set at the ground level, with continued compatibility and openness as core principles. It'd be a big project, it would constrict some freedoms, and it would have to be done by people with far more tech savvy and foresight than myself, but it seems to me that medical computing will devolve into a cluttered mess if not done the *sigh* Apple way.
(I realize I may be oversimplifying this ridiculously; I am a bit out of my depth)
posted by es_de_bah at 10:04 AM on December 1, 2009 [1 favorite]
I guess the reason I found this so fascinating is that it highlights the difference between the claimed benefits of technology ("computers will save us lots of money!") vs. the actual benefits of the technology (modest benefits in quality of care, negligible cost savings).
Now, regardless of the results of this study, and any other number of studies that may come out in the future, I am guessing that people will continue to claim that "computerized health care will save us tons of money!" as a way of selling this idea to hospitals and health care clinics.
In my own company, the corporate heads decided at some point that it would be a good idea to develop a centralized order entry system for our sales reps. Eight years later we are just barely rolling out this system, which was supposed to save tons of money and labor. It's clunky, it's already dated, and the cost savings are actually negative when compared to the immense cost of development and deployment.
Companies (health care facilities and hospitals included) seem to be unaware that effective software development is a wild animal, difficult for people to handle unless they know exactly what they're dealing with. Getting good technical people in charge of development is essential, but it can be almost impossible for non-technical companies to do this.
posted by eleyna at 10:06 AM on December 1, 2009 [3 favorites]
Now, regardless of the results of this study, and any other number of studies that may come out in the future, I am guessing that people will continue to claim that "computerized health care will save us tons of money!" as a way of selling this idea to hospitals and health care clinics.
In my own company, the corporate heads decided at some point that it would be a good idea to develop a centralized order entry system for our sales reps. Eight years later we are just barely rolling out this system, which was supposed to save tons of money and labor. It's clunky, it's already dated, and the cost savings are actually negative when compared to the immense cost of development and deployment.
Companies (health care facilities and hospitals included) seem to be unaware that effective software development is a wild animal, difficult for people to handle unless they know exactly what they're dealing with. Getting good technical people in charge of development is essential, but it can be almost impossible for non-technical companies to do this.
posted by eleyna at 10:06 AM on December 1, 2009 [3 favorites]
Usually, when I hear arguments in favor of large-scale computerization of hospital records, the primary reasoning is to enable easy transfer of medical data between facilities, which means not "everybody builds a really expensive custom solution" but "sensible standards are agreed upon for data exchange."
I think part of the problem is that, although we shouldn't be spending a lot of money reinventing the wheel, apparently the wheel hasn't actually been invented yet. That is, no one has yet made a good, complete, non-proprietary, easily customized, robust solution.
Most vendors promote vertically-integrated solutions designed to produce vendor lock-in. Faced with a choice between a custom solution from a vendor and a custom solution built in-house, the wise choice seems to be the in-house solution. And that isn't very surprising: apparently most of the 'custom' solutions from vendors are actually pretty slap-dash, one-size-fits-all affairs shoe horned into the client's environment.
the money saved from those gains aren't plowed back into making other parts of the system work better. It just goes into someone's pocket.
That's also probably a big part of it. The Robert Wood Johnson Foundation found in 2008 that tort reform, for example, didn't actually reduce the cost of health insurance: the modest cost savings just went into health insurance company profits. It also didn't reduce the cost of malpractice insurance, it just reduced the rate of growth. Nor did it actually change the way most doctors practice medicine; defensive medicine remained the norm in most practice areas.
posted by jedicus at 10:07 AM on December 1, 2009 [8 favorites]
I think part of the problem is that, although we shouldn't be spending a lot of money reinventing the wheel, apparently the wheel hasn't actually been invented yet. That is, no one has yet made a good, complete, non-proprietary, easily customized, robust solution.
Most vendors promote vertically-integrated solutions designed to produce vendor lock-in. Faced with a choice between a custom solution from a vendor and a custom solution built in-house, the wise choice seems to be the in-house solution. And that isn't very surprising: apparently most of the 'custom' solutions from vendors are actually pretty slap-dash, one-size-fits-all affairs shoe horned into the client's environment.
the money saved from those gains aren't plowed back into making other parts of the system work better. It just goes into someone's pocket.
That's also probably a big part of it. The Robert Wood Johnson Foundation found in 2008 that tort reform, for example, didn't actually reduce the cost of health insurance: the modest cost savings just went into health insurance company profits. It also didn't reduce the cost of malpractice insurance, it just reduced the rate of growth. Nor did it actually change the way most doctors practice medicine; defensive medicine remained the norm in most practice areas.
posted by jedicus at 10:07 AM on December 1, 2009 [8 favorites]
Have you seen most hospital computer systems? It's no wonder they're not saving money, they have antiquated and disparate systems with counterintuitive interfaces. Computers don't save hospitals money in the same sense that cars aren't an effective form of transportation when by "car" you mean "lawnmower engine bolted to some bicycle tires".
Programmers of the successful systems told Himmelstein that they didn't write manuals or offer training. "If you need a manual, then the system doesn't work. If you need training, the system doesn't work," he said.
What an ironic viewpoint under the circumstances. Yeah, no system that requires manuals or training can be any good.
I know what he's getting at with that statement. It's a classic user interface guideline that users don't read. But the real problem is that "put it in the manual" or "we'll just add that to the training course" is used as a cost-cutting measure when the development team doesn't feel they have the time, resources, or skill to redesign a confusing interface.
The more appropriate UI rule should be this: make everything as simple as possible, but not simpler. For something complex like medical technology, sometimes you'll make the system worse, not better by trying to make it easier to use. If a doctor has to go through a six-step wizard every time she enters a prescription, she's not going to thank the developers for holding her hand through it.
As simple as possible, but no simpler.
posted by Riki tiki at 10:10 AM on December 1, 2009 [8 favorites]
Programmers of the successful systems told Himmelstein that they didn't write manuals or offer training. "If you need a manual, then the system doesn't work. If you need training, the system doesn't work," he said.
What an ironic viewpoint under the circumstances. Yeah, no system that requires manuals or training can be any good.
I know what he's getting at with that statement. It's a classic user interface guideline that users don't read. But the real problem is that "put it in the manual" or "we'll just add that to the training course" is used as a cost-cutting measure when the development team doesn't feel they have the time, resources, or skill to redesign a confusing interface.
The more appropriate UI rule should be this: make everything as simple as possible, but not simpler. For something complex like medical technology, sometimes you'll make the system worse, not better by trying to make it easier to use. If a doctor has to go through a six-step wizard every time she enters a prescription, she's not going to thank the developers for holding her hand through it.
As simple as possible, but no simpler.
posted by Riki tiki at 10:10 AM on December 1, 2009 [8 favorites]
Cool Papa Bell wrote: "Health care costs more because health care providers are charging more. Period."
Look at a local or regional hospital operator's balance sheet. You may find yourself disabused of the notion that they are the robber barons of the health care industry.
I'm not at all saying costs are out of control, they are. I think it's more due to the absurdly high cost of drugs, medical equipment, and insurance than the providers themselves (by and large, there are some exceptions).
It's probably also helped along by the data interchange issue.
posted by wierdo at 10:17 AM on December 1, 2009 [1 favorite]
Look at a local or regional hospital operator's balance sheet. You may find yourself disabused of the notion that they are the robber barons of the health care industry.
I'm not at all saying costs are out of control, they are. I think it's more due to the absurdly high cost of drugs, medical equipment, and insurance than the providers themselves (by and large, there are some exceptions).
It's probably also helped along by the data interchange issue.
posted by wierdo at 10:17 AM on December 1, 2009 [1 favorite]
Just one more SAP integration project!
posted by Artw at 10:19 AM on December 1, 2009 [3 favorites]
posted by Artw at 10:19 AM on December 1, 2009 [3 favorites]
I have said it before and I'll say it again:
Someday people will do all the things that computers do today.
posted by flarbuse at 10:21 AM on December 1, 2009 [8 favorites]
Someday people will do all the things that computers do today.
posted by flarbuse at 10:21 AM on December 1, 2009 [8 favorites]
From most of what I've seen of internal corporate IT, the reason computers don't save money is that 95% of internally developed software is just absolute garbage
FTFY. HTH. HAND!
But seriously. The reason that it hasn't helped anybody but admin until very recently is that computing in the office was built for the office, and the interfaces were useless squared to providers. Not that paper charts were drastically better, but protocols that were developed to allow them to be used safely didn't easily translate to conventional computer keyboard and mouse.
Example: How do you keep a keyboard, that you have to touch with your hands, sterile? You might contaminate a piece of paper, which can be transcribed and destroyed, and of course, since you can easily use a new piece of paper every time, you can avoid cross transmission, but a keyboard? That's hard.*
I've mentioned VistA (not Windows Vista, mind you) before. It's focus is on EHR and EHR+Imaging, but the important thing about it is that it the development team went out and watched how the system was being used, and what problems it was causing, then worked out how to make those interfaces better.
Most diagnostic systems fail badly in the provider area. They're okay for the admin staff, but for IT to directly help outcomes, it needs to be easily accessible at the treatment stage -- that is, it needs to not be any slower than what it is replacing, while being better otherwise, and, of course, not being a noscomial infection source.
VistA, in fact, is how to do it correctly -- or, at least, much closer to correctly. Many proprietary systems -- both off the shelf and bespoke -- fail badly, except for the admin side, because they're built with the tools and interfaces that the admin side can use easily, but the provider side cannot. By working with providers, VistA has interfaces that the providers can work with. They still have a long way to go, but they at least understand where the problems are.
posted by eriko at 10:22 AM on December 1, 2009 [3 favorites]
FTFY. HTH. HAND!
But seriously. The reason that it hasn't helped anybody but admin until very recently is that computing in the office was built for the office, and the interfaces were useless squared to providers. Not that paper charts were drastically better, but protocols that were developed to allow them to be used safely didn't easily translate to conventional computer keyboard and mouse.
Example: How do you keep a keyboard, that you have to touch with your hands, sterile? You might contaminate a piece of paper, which can be transcribed and destroyed, and of course, since you can easily use a new piece of paper every time, you can avoid cross transmission, but a keyboard? That's hard.*
I've mentioned VistA (not Windows Vista, mind you) before. It's focus is on EHR and EHR+Imaging, but the important thing about it is that it the development team went out and watched how the system was being used, and what problems it was causing, then worked out how to make those interfaces better.
Most diagnostic systems fail badly in the provider area. They're okay for the admin staff, but for IT to directly help outcomes, it needs to be easily accessible at the treatment stage -- that is, it needs to not be any slower than what it is replacing, while being better otherwise, and, of course, not being a noscomial infection source.
VistA, in fact, is how to do it correctly -- or, at least, much closer to correctly. Many proprietary systems -- both off the shelf and bespoke -- fail badly, except for the admin side, because they're built with the tools and interfaces that the admin side can use easily, but the provider side cannot. By working with providers, VistA has interfaces that the providers can work with. They still have a long way to go, but they at least understand where the problems are.
posted by eriko at 10:22 AM on December 1, 2009 [3 favorites]
Well if we had government-run healthcare, at least everyone would be using the same crappy IT setup. Which might in theory be reformable.
Seems privatized healthcare has instead been an excellent medium for an explosion in the varieties of crappy IT. Which isn't working. We need a replacement for all of these varieties. And that system will not be handwritten records.
Isn't that what should be brought up here? Going back to typewriters and penciled-in entries as permanent records is not an option. There is too much need to accumulate data, archive, and retrieve it to make that viable. Presumably no one is saying we don't need to use some form of computer records in hospitals.
So instead of just bitching about it as some sort of Obama boondoggle (which is the slant the article seems to be taking), maybe we can look at some of the reasons it has been failing and do something constructive.
In this thread, commenters have figured out pretty quickly that poor design and too much customization is one issue.
I would add that another issue might be that almost all complex medical equipment is computerized in some way, but is it all geared to a universal setup or connection of any kind? It should be. Do we require device manufacturers to comply? Can we not create standards and requirements that software could be written to and hardware designed that allow more connectivity and adaptation?
I'm asking because the particulars of all of that is over my head, of course.
posted by emjaybee at 10:24 AM on December 1, 2009 [1 favorite]
Seems privatized healthcare has instead been an excellent medium for an explosion in the varieties of crappy IT. Which isn't working. We need a replacement for all of these varieties. And that system will not be handwritten records.
Isn't that what should be brought up here? Going back to typewriters and penciled-in entries as permanent records is not an option. There is too much need to accumulate data, archive, and retrieve it to make that viable. Presumably no one is saying we don't need to use some form of computer records in hospitals.
So instead of just bitching about it as some sort of Obama boondoggle (which is the slant the article seems to be taking), maybe we can look at some of the reasons it has been failing and do something constructive.
In this thread, commenters have figured out pretty quickly that poor design and too much customization is one issue.
I would add that another issue might be that almost all complex medical equipment is computerized in some way, but is it all geared to a universal setup or connection of any kind? It should be. Do we require device manufacturers to comply? Can we not create standards and requirements that software could be written to and hardware designed that allow more connectivity and adaptation?
I'm asking because the particulars of all of that is over my head, of course.
posted by emjaybee at 10:24 AM on December 1, 2009 [1 favorite]
One of the problems with health care IT is that most "medical records" are just free-form text narratives written by physicians - the Medical History & Physical, interpretations of scans/xrays, progress notes, assessments. It's not really something that "computerizes" well. Sadder still, institutions don't seem to know what to do with that data that is structured or validatable (like meds, dosages, vital signs, time stamps).
I'm a new RN and an ex-industrial engineer. I work bedside at a large teaching hospital and it's a really exciting time in health care operations right now. Hospitals are currently run like small craft-villages. The pressure to adopt industrial techniques is getting stronger and being met with a combination of bafflement and resistance. Given my experience with MRP/II and migrations to ERP systems, I'm not sure modern manufacturing is the most desirable model to shoehorn health care into. (Oh yeah, any hospital management software I've ever seen is total shit in every way. Total Shit.)
posted by klarck at 10:27 AM on December 1, 2009 [4 favorites]
I'm a new RN and an ex-industrial engineer. I work bedside at a large teaching hospital and it's a really exciting time in health care operations right now. Hospitals are currently run like small craft-villages. The pressure to adopt industrial techniques is getting stronger and being met with a combination of bafflement and resistance. Given my experience with MRP/II and migrations to ERP systems, I'm not sure modern manufacturing is the most desirable model to shoehorn health care into. (Oh yeah, any hospital management software I've ever seen is total shit in every way. Total Shit.)
posted by klarck at 10:27 AM on December 1, 2009 [4 favorites]
I'm been following medical software solutions for 2 decades now. Family members have their own clinics and I've often gotten asked for advice by my own doctor. We've looked at PC systems, Mac systems, mobile systems (think back to Apple Newton...), "ASP" hosted systems delivered almost entirely via a web browser (garbage) and most recently "Tablet" systems.
The only common-denominator is that they ALL suck.
Hospital systems, clinic management systems, systems that while "designed" by doctors wwere implemented by the lowest bid programming contractor with no data and/or usability designer/architect in-place. On analysis you could quickly tell that each physician with an investment into the system wanted a specific feature - but none those modules worked properly together - hell, they didn't even look like the same system.
Systems where, if you press the "TAB" key to move from one field to another (a standard keyboarding mechanism for decades) your focus jumps randomly, never the same way twice - making quick keyboard navigation impossible.
And of course... what makes these things less profitable to design is that the back-end billing is different region-to-region, country-to-country.
Sigh, it's depressing - because in the business world we've learned these lessons - medical software is still stuck in 1988...
posted by jkaczor at 10:27 AM on December 1, 2009 [3 favorites]
The only common-denominator is that they ALL suck.
Hospital systems, clinic management systems, systems that while "designed" by doctors wwere implemented by the lowest bid programming contractor with no data and/or usability designer/architect in-place. On analysis you could quickly tell that each physician with an investment into the system wanted a specific feature - but none those modules worked properly together - hell, they didn't even look like the same system.
Systems where, if you press the "TAB" key to move from one field to another (a standard keyboarding mechanism for decades) your focus jumps randomly, never the same way twice - making quick keyboard navigation impossible.
And of course... what makes these things less profitable to design is that the back-end billing is different region-to-region, country-to-country.
Sigh, it's depressing - because in the business world we've learned these lessons - medical software is still stuck in 1988...
posted by jkaczor at 10:27 AM on December 1, 2009 [3 favorites]
This is the productivity paradox. An MIT study (Landauer, 1995) found the same thing in office "productivity" software in the 1980s (actually they found that IT spending was slightly negatively correlated wtih profit). As said above, much software is not usable, and not useful.
posted by anthill at 10:31 AM on December 1, 2009
posted by anthill at 10:31 AM on December 1, 2009
Cool Papa Bell: No, computers won't make your broken arm heal faster. But they will make your bill show up faster and more efficiently.
Hrm, this actually confirms Thomas Landauer's hypothesis that information technology primarily results in gains in productivity if you follow the model of telecommunications back in the 80s: completely automate formerly labor-intensive systems and downsize a large chunk of your workforce. The adoption of word processors didn't result in increases in either productivity or accuracy in business communication, because you raised the bar on what was formerly a two-draft process, and you ended up paying executives to copyedit rather than delegating that task to administrative assistants.
Any potential gains you get in efficiency is swamped by the fact that you still have human beings involved in the process. Computerizing billing isn't going to do much good if you still depend on highly-trained staff to code, check, and enter those billing and diagnosis codes, and insurance adjusters doing their own analysis of bills.
I'm pretty convinced that better software doesn't necessarily make what are essentially labor-intensive processes more efficient. And I don't think that this is a case where human labor can or should be cut out of the process.
On preview: what anthill said. Landauer is sobering reading for people who believe that tools and interfaces can magically make things better.
posted by KirkJobSluder at 10:36 AM on December 1, 2009 [5 favorites]
Hrm, this actually confirms Thomas Landauer's hypothesis that information technology primarily results in gains in productivity if you follow the model of telecommunications back in the 80s: completely automate formerly labor-intensive systems and downsize a large chunk of your workforce. The adoption of word processors didn't result in increases in either productivity or accuracy in business communication, because you raised the bar on what was formerly a two-draft process, and you ended up paying executives to copyedit rather than delegating that task to administrative assistants.
Any potential gains you get in efficiency is swamped by the fact that you still have human beings involved in the process. Computerizing billing isn't going to do much good if you still depend on highly-trained staff to code, check, and enter those billing and diagnosis codes, and insurance adjusters doing their own analysis of bills.
I'm pretty convinced that better software doesn't necessarily make what are essentially labor-intensive processes more efficient. And I don't think that this is a case where human labor can or should be cut out of the process.
On preview: what anthill said. Landauer is sobering reading for people who believe that tools and interfaces can magically make things better.
posted by KirkJobSluder at 10:36 AM on December 1, 2009 [5 favorites]
The problem is that data like financial transactions are relational and follow rules. This makes sense as they're a constructed abstraction. If you're doing 20 million transactions you've got a pretty clear path on how to do 40 million transactions and the increase in actual operating costs is nothing.
With hospitals at most you're going to save an administrative burden and the efficiency gained is going to be finite and pretty small. If you're going to really be making gains it would be in better diagnosis. With thousands of diagnosis and conditions you can't really organize it. "Left upper back, dull pain" might be another doctor's "left shoulder, moderate pain." The only real way to mitigate this would be to take a 3D scan so if 20 years down the road you feel the same pain they can look it up and see that you're talking about the exact same spot. Not just the general area, but within an inch of where it was 20 years ago. Good luck on trying to develop a 3D scan standard. A doctor can't even look up which prescriptions I took, if I took some obscure allergy medicine and came in 10 years later with symptoms of a migraine the doctor isn't going to know I was on a medication that was recalled due causing brain tumors. At best I would know, but if I stop taking it before the recall, who knows? It might eventually be caught, sure, but you're not going to get a House MD all the time, or even in time to catch anything.
That's not even beginning to get in with MRIs, x-rays and the myriad of other technologies that aren't standardized and shared unless it is immediate (and I don't know how it works now, but I assume a lot of it is probably still physically delivered if you end up going to different hospitals).
The AEC industry has the same problem. In the 80s everyone thought CADs would change everything, object oriented databases were the next big thing. And sure they're used a lot, but screen resolutions are still low and somewhere along the line they're going to be printed up and marked up. Suddenly the real advantages of CAD, that you can virtually build something, are completely lost. The expectation is that they'll be printed out and you still rely on mechanical and electrical subcontractors to fill in the details. Large projects or ones with really complex process piping and electrical systems will have engineers actually build it twice, virtually, and it does end up saving a lot of money. But such projects are usually very vertical and you're not sharing information via standards as much as imposing a way of doing something, within a proprietary system. Some things are just too hard to standardize.
It does not surprise me that custom in-house systems are the ones that end up saving money. For a lot of industries, particularly those that fall under the category of professional services, you're just not going to see the gains you would as a product based company.
I have said, probably here, that as the requirements to learn how to program drop and you begin to see business departments requiring Java, but not touching processor design or nuts and bolts work, you're going to see more and more domain experts pickup these tools and see what can be done with relative ease. I know there's sort of a stigma attached to not being a classically trained programmer, but I see it as more of an opportunity that you have people with decision making power at least have an idea what can be done and hire a competent programmer with a scope of work that's not absurd. It is good for everyone, can you imagine building houses and the owner coming to you asking if they can push out the living room by 5 feet two days before completion because it "doesn't seem like that much?"
posted by geoff. at 10:44 AM on December 1, 2009 [7 favorites]
With hospitals at most you're going to save an administrative burden and the efficiency gained is going to be finite and pretty small. If you're going to really be making gains it would be in better diagnosis. With thousands of diagnosis and conditions you can't really organize it. "Left upper back, dull pain" might be another doctor's "left shoulder, moderate pain." The only real way to mitigate this would be to take a 3D scan so if 20 years down the road you feel the same pain they can look it up and see that you're talking about the exact same spot. Not just the general area, but within an inch of where it was 20 years ago. Good luck on trying to develop a 3D scan standard. A doctor can't even look up which prescriptions I took, if I took some obscure allergy medicine and came in 10 years later with symptoms of a migraine the doctor isn't going to know I was on a medication that was recalled due causing brain tumors. At best I would know, but if I stop taking it before the recall, who knows? It might eventually be caught, sure, but you're not going to get a House MD all the time, or even in time to catch anything.
That's not even beginning to get in with MRIs, x-rays and the myriad of other technologies that aren't standardized and shared unless it is immediate (and I don't know how it works now, but I assume a lot of it is probably still physically delivered if you end up going to different hospitals).
The AEC industry has the same problem. In the 80s everyone thought CADs would change everything, object oriented databases were the next big thing. And sure they're used a lot, but screen resolutions are still low and somewhere along the line they're going to be printed up and marked up. Suddenly the real advantages of CAD, that you can virtually build something, are completely lost. The expectation is that they'll be printed out and you still rely on mechanical and electrical subcontractors to fill in the details. Large projects or ones with really complex process piping and electrical systems will have engineers actually build it twice, virtually, and it does end up saving a lot of money. But such projects are usually very vertical and you're not sharing information via standards as much as imposing a way of doing something, within a proprietary system. Some things are just too hard to standardize.
It does not surprise me that custom in-house systems are the ones that end up saving money. For a lot of industries, particularly those that fall under the category of professional services, you're just not going to see the gains you would as a product based company.
I have said, probably here, that as the requirements to learn how to program drop and you begin to see business departments requiring Java, but not touching processor design or nuts and bolts work, you're going to see more and more domain experts pickup these tools and see what can be done with relative ease. I know there's sort of a stigma attached to not being a classically trained programmer, but I see it as more of an opportunity that you have people with decision making power at least have an idea what can be done and hire a competent programmer with a scope of work that's not absurd. It is good for everyone, can you imagine building houses and the owner coming to you asking if they can push out the living room by 5 feet two days before completion because it "doesn't seem like that much?"
posted by geoff. at 10:44 AM on December 1, 2009 [7 favorites]
I live in Kansas City, and among the big employers in the area is Cerner. Cerner builds, sells and installs medical IT, primarily billing. Looking at Cerner's business statistics it is not surprising to me that most of the benefit is going to Cerner versus the hospital. Mostly because their margins are so high, but also because every other "enterprise" tool I've encountered outside medicine has also been just outright terrible.
Part of the problem, as I understand things, is that hospitals are not well integrated. They're non-profits that compete to receive doctor's patients. Because the system is fragmented, IT can't be applied to core business functions. You can computerize billing, but diagnosis isn't the hospital's job. Retailers use IT to track prices and margins and order efficiently. Insurance companies use IT to handle actuarial computation.
The light at the end of the tunnel appears to be the open source VA tool ViSTA. Yay FOIA.
posted by pwnguin at 10:44 AM on December 1, 2009 [2 favorites]
Part of the problem, as I understand things, is that hospitals are not well integrated. They're non-profits that compete to receive doctor's patients. Because the system is fragmented, IT can't be applied to core business functions. You can computerize billing, but diagnosis isn't the hospital's job. Retailers use IT to track prices and margins and order efficiently. Insurance companies use IT to handle actuarial computation.
The light at the end of the tunnel appears to be the open source VA tool ViSTA. Yay FOIA.
posted by pwnguin at 10:44 AM on December 1, 2009 [2 favorites]
Great article; I work in healthcare IT, and it struck me as absolutely right on.
I've seen scenarios where given the choice between:
A) Brand new WhizBang Billing System 3000 (now with HIPAA compliance auditing! Automated HFCA 837 transfers!) implentation. Will required bow-tied consultants on site for the next decade. Capital expenditure to start in the low eight figures.
B) A warehouse full of people filling out forms with pencils.
B is the compelling economic victor.
posted by mrdaneri at 10:49 AM on December 1, 2009 [1 favorite]
I've seen scenarios where given the choice between:
A) Brand new WhizBang Billing System 3000 (now with HIPAA compliance auditing! Automated HFCA 837 transfers!) implentation. Will required bow-tied consultants on site for the next decade. Capital expenditure to start in the low eight figures.
B) A warehouse full of people filling out forms with pencils.
B is the compelling economic victor.
posted by mrdaneri at 10:49 AM on December 1, 2009 [1 favorite]
Good luck on trying to develop a 3D scan standard.
Actually, everyone uses DICOM. The problem is that DICOM has about a thousand fields that no one uses uniformly.
posted by demiurge at 10:51 AM on December 1, 2009 [1 favorite]
Actually, everyone uses DICOM. The problem is that DICOM has about a thousand fields that no one uses uniformly.
posted by demiurge at 10:51 AM on December 1, 2009 [1 favorite]
Scanning this thread, I've seen words like 'contempt' and 'terrible' and so on applied to the UI of these medical software systems and their designers.
As a point of note, I'd like to say that UI design is much, much more difficult to get right than it seems from the outside, even when the client is willing to pay for it. Enterprise software in general suffers from a crippling business flaw with respect to UI: the people who *buy* it have different priorities from the people who *use* it. Actual end-users aren't involved early enough in the design process; designers, when present, aren't given enough time or power to get their designs done right; users don't know what they want.
It's a really, really hard problem and, though it is real, it's incompetence rather than malice that causes these bad designs.
posted by Fraxas at 11:02 AM on December 1, 2009 [3 favorites]
As a point of note, I'd like to say that UI design is much, much more difficult to get right than it seems from the outside, even when the client is willing to pay for it. Enterprise software in general suffers from a crippling business flaw with respect to UI: the people who *buy* it have different priorities from the people who *use* it. Actual end-users aren't involved early enough in the design process; designers, when present, aren't given enough time or power to get their designs done right; users don't know what they want.
It's a really, really hard problem and, though it is real, it's incompetence rather than malice that causes these bad designs.
posted by Fraxas at 11:02 AM on December 1, 2009 [3 favorites]
My dentist has a fancy computer system, and I've seen them entering the data. It seems clear that the focus is on flexibility to enter anything and on new features like seeing x-rays, at the expense of speed of data entry. The fields that are updated for a single visit are spread all over the place, and require a dozen clicks. I'm sure it's a time waste, but the dentist probably chose the program for the features rather than the usability.
posted by smackfu at 11:05 AM on December 1, 2009 [2 favorites]
posted by smackfu at 11:05 AM on December 1, 2009 [2 favorites]
The computer software we used when I worked as a radiology clerk (in 2002) was archaic and barely worked with the systems used in other departments. Essentially, we had a big paper file on any patient brought into radiology with their x-rays, exam transcripts, etc. We assigned them a number that was entered into OUR database. This was in no way related to their number in the hospital database, which we had to look up separately and cross-reference to our internal number. It was really, ridiculously easy to accidentally press ENTER at the wrong time and zero out a patient's radiological record number. I did this myself on several occasions and spent a whole afternoon trying to track down a patient file that had been zeroed out by a clerk with over 5 years of experience with the system. "It happens." Not to mention the fact that we had to interface with ER and sometimes a clerk over there would assign a number without checking with us first, causing lots of wasted time.
And our software ultimately didn't prevent the #1 cause of lost records - a clerk mislabeling the paper file with the wrong color code. This happened just before I started working at the hospital, and wasn't caught until a PCP realized that he never received the results of the GI Tract x-ray/barium enema (not a pleasant test to repeat, I've been told).
posted by muddgirl at 11:09 AM on December 1, 2009
And our software ultimately didn't prevent the #1 cause of lost records - a clerk mislabeling the paper file with the wrong color code. This happened just before I started working at the hospital, and wasn't caught until a PCP realized that he never received the results of the GI Tract x-ray/barium enema (not a pleasant test to repeat, I've been told).
posted by muddgirl at 11:09 AM on December 1, 2009
Tony Collins has been saying very similar things for a long time, although I would add that I don't think money should be the driving factor in healthcare - adding new technology should be all about improving patient care.
The contract clause I'd like to see: "if the hospital mortality rate rises by more than 2% after installing this software, the entire cost of the project will be refunded"
CRASH: Ten Ways to Avoid a Computer Disaster by Tony Collins (Amazon)
The 10 themes
1. A Tendency to be overambitious
2. A feeling among computer managers that they should know it all, and cannot admit when they don't.
3. A belief among the entire project team that computerisation must be a good thing, and to suspect otherwise is an Orwellian thought-crime.
4. A chief executive who is in the best position to judge a computer project because he knows nothing about computers but fails to intervene,because he knows nothing about computers.
5. A readiness to accept it'll be alright-on-the-night assurances from suppliers - assurances that suppliers studiously avoid writing down.
6. An over-reliance on consultants who, like some vets, may have a financial interest in prolonging ills.
7. An avoidance of cheap, proven, off-the-shelf packages in favour of costly, unproven, custom built software; or worse the tailoring of a standard proven package.
8. An unwillingness by middle and senior management to impart bad news to the board - mainly because the board will make known its resentment of anyone who tries.
9. The buck stops nowhere.
10. A mistaken belief that the contract makes it easy to sue the supplier if it all goes wrong
posted by Lanark at 11:09 AM on December 1, 2009 [3 favorites]
The contract clause I'd like to see: "if the hospital mortality rate rises by more than 2% after installing this software, the entire cost of the project will be refunded"
CRASH: Ten Ways to Avoid a Computer Disaster by Tony Collins (Amazon)
The 10 themes
1. A Tendency to be overambitious
2. A feeling among computer managers that they should know it all, and cannot admit when they don't.
3. A belief among the entire project team that computerisation must be a good thing, and to suspect otherwise is an Orwellian thought-crime.
4. A chief executive who is in the best position to judge a computer project because he knows nothing about computers but fails to intervene,because he knows nothing about computers.
5. A readiness to accept it'll be alright-on-the-night assurances from suppliers - assurances that suppliers studiously avoid writing down.
6. An over-reliance on consultants who, like some vets, may have a financial interest in prolonging ills.
7. An avoidance of cheap, proven, off-the-shelf packages in favour of costly, unproven, custom built software; or worse the tailoring of a standard proven package.
8. An unwillingness by middle and senior management to impart bad news to the board - mainly because the board will make known its resentment of anyone who tries.
9. The buck stops nowhere.
10. A mistaken belief that the contract makes it easy to sue the supplier if it all goes wrong
posted by Lanark at 11:09 AM on December 1, 2009 [3 favorites]
On the other hand, the study also says "More encouragingly, greater use of information technology was associated with a consistent though small increase in quality scores." (Quality of health care, that is).
...
No, computers won't make your broken arm heal faster. But they will make your bill show up faster and more efficiently.
That seems to be the real rub to me. I recently broke some parts and I was amazed at how quickly my hospital could take my x-rays, get them into the system, and have my doctor analyze them and discuss them with me. The whole process was like 15 minutes.
Nurses are very intelligent and technically minded people... and they're made to feel like helpless idiots by the programs they're expected to use.
That's the fault of the hospital perhaps. At mine, the nurses don't use computers much at all. That job goes to trained "medical assistants" and of course adminstrative/billing/records.
posted by mrgrimm at 11:15 AM on December 1, 2009
...
No, computers won't make your broken arm heal faster. But they will make your bill show up faster and more efficiently.
That seems to be the real rub to me. I recently broke some parts and I was amazed at how quickly my hospital could take my x-rays, get them into the system, and have my doctor analyze them and discuss them with me. The whole process was like 15 minutes.
Nurses are very intelligent and technically minded people... and they're made to feel like helpless idiots by the programs they're expected to use.
That's the fault of the hospital perhaps. At mine, the nurses don't use computers much at all. That job goes to trained "medical assistants" and of course adminstrative/billing/records.
posted by mrgrimm at 11:15 AM on December 1, 2009
I'd love to get to design hospital information system. It would include colored 'quest' cards that patients, doctors and nurses receive and fill in each complicated process with instructions of where to go next and what to do. Go with the cardboard, digitize only for posteriority or for backup.
posted by Free word order! at 11:19 AM on December 1, 2009
posted by Free word order! at 11:19 AM on December 1, 2009
Computerization will not save anyone money until it is:
- Completely integrated: EHR needs to include ALL patient data in one place-- this includes information from bedside monitors, labwork, pharmacy, and home monitoring (BP, HgbA1C, FEV, &c) systems. The more integrated the system, the more diagnostically helpful EHR becomes. Example: most patients with sepsis and acute kidney injury die, but fewer die when the sepsis is diagnosed quickly. Computerized monitoring of bedside monitor data could more quickly detect spikes in body temperature and decreased blood pressure, allowing for faster treatment and better management. These systems should also integrate with disease registries
- Entirely Portable: records should be accessible from anywhere, and should present data in a variety of ways depending on the audience. Docs should get all the clinical details; insurance companies should see the billing side; patients should be able to track valuable indicators like HgbA1C, BMI, and BP over time. This not only eliminates the costs of records transfer that Tomorrowful wrote of, but it also empowers the patient, allowing him or her to better manage or prevent chronic conditions such as diabetes and obesity.
- User Friendly: an ideal system, as they wired article pointed out, is one that requires no training. We reached the point years ago where computer programs could interpret simple english syntax-- there's no reason these systems need to put nurses through fifteen context menus just to write "loose stools."
I actually work for a company that develops (among other things) health care automation systems, and while I don't want to be defensive about the serious accusations the article makes, it struck me that the study doesn't differentiate well between different automated functions within a typical hospital, or even between what a general electronic record system does and other ways of using computer-based data in a hospital (say, for taking patient menus at bedsides, planning menus based on patient choice history, ensuring diet compliance with doctor's orders, or making dining inventory more cost-efficient). By relying so heavily on the HIMSS data (the relatively narrow range of admissions and billing hospital functions covered is on the bottom right of pg. 2 of the actual study), they missed looking at a whole other world of potentially more successful and cost-saving computer use happening every day. The author's concluding statement just betrays his shallow knowledge of what he's publishing his sensational article about.
posted by aught at 11:41 AM on December 1, 2009 [5 favorites]
posted by aught at 11:41 AM on December 1, 2009 [5 favorites]
Sigh, it's depressing - because in the business world we've learned these lessons - medical software is still stuck in 1988...
I dunno that the business world has learned this either. Take a look at what's out there right now for ERP or CRM applications re: proprietary data formats, crummy UI, incredibly hard to integrate, resource hogging...
It's not pretty, lemme tell you.
posted by Zinger at 11:41 AM on December 1, 2009 [2 favorites]
I dunno that the business world has learned this either. Take a look at what's out there right now for ERP or CRM applications re: proprietary data formats, crummy UI, incredibly hard to integrate, resource hogging...
It's not pretty, lemme tell you.
posted by Zinger at 11:41 AM on December 1, 2009 [2 favorites]
No, computers won't make your broken arm heal faster. But they will make your bill show up faster and more efficiently.
Really? Last week I got a collections call for a bill that hadn't even been issued yet. When will these wonderful 'computers' come?
posted by mattholomew at 11:52 AM on December 1, 2009
Really? Last week I got a collections call for a bill that hadn't even been issued yet. When will these wonderful 'computers' come?
posted by mattholomew at 11:52 AM on December 1, 2009
Health care costs more because health care providers are charging more. Period.
Honestly I'm not trying to troll here, but where are you getting this information from? Because the "This American Life" episodes on the costs of health care suggested that it's far more complex than just 'charging more'.
posted by mattholomew at 11:55 AM on December 1, 2009
Honestly I'm not trying to troll here, but where are you getting this information from? Because the "This American Life" episodes on the costs of health care suggested that it's far more complex than just 'charging more'.
posted by mattholomew at 11:55 AM on December 1, 2009
the people who *buy* it have different priorities from the people who *use* it
This is exactly right, for just about any corporate computer system I've seen over the years. The guy in charge of implementing the system has to return to the higher ups, not the users, the benchmark is usually i.e. keeping it low. Guess how you keep it low? Skip user testing, hiring professional coders with a proven track record etc, etc. And lets not forget the makers of these systems have no reason to make things god and easy 'cause if they do that, then they can't charge for support and there aren't many companies that are going to eliminate a revenue stream.
posted by Brandon Blatcher at 11:58 AM on December 1, 2009 [1 favorite]
This is exactly right, for just about any corporate computer system I've seen over the years. The guy in charge of implementing the system has to return to the higher ups, not the users, the benchmark is usually i.e. keeping it low. Guess how you keep it low? Skip user testing, hiring professional coders with a proven track record etc, etc. And lets not forget the makers of these systems have no reason to make things god and easy 'cause if they do that, then they can't charge for support and there aren't many companies that are going to eliminate a revenue stream.
posted by Brandon Blatcher at 11:58 AM on December 1, 2009 [1 favorite]
No, computers won't make your broken arm heal faster. But they will make your bill show up faster and more efficiently.It will help the bill show up faster, but it will also allow doctors and nurses to get your medical records quicker, and be able to look up relevant information on your condition quicker, and they'll be able to use expert systems to aide diagnosis as well.
In other words, there areefficiency gains. But the money saved from those gains aren't plowed back into making other parts of the system work better. It just goes into someone's pocket.
There is more to medicine then billing.
posted by delmoi at 12:01 PM on December 1, 2009
A note on a paper chart that takes three seconds is now five solid minutes of hunting through menu options, screens, and mandatory text fields.
Yeah, but I get the impression that the standardized, coded note in the IT system is more accessible, more easily communicated to other systems, easier to read, process and search through than a note on a piece of paper.
posted by splice at 12:03 PM on December 1, 2009 [2 favorites]
Yeah, but I get the impression that the standardized, coded note in the IT system is more accessible, more easily communicated to other systems, easier to read, process and search through than a note on a piece of paper.
posted by splice at 12:03 PM on December 1, 2009 [2 favorites]
Honestly I'm not trying to troll here, but where are you getting this information from? Because the "This American Life" episodes on the costs of health care suggested that it's far more complex than just 'charging more'.
Higher costs then other countries are a big factor in our healthcare costs though. Here's an Ezra Klein article about it. Obviously it's complicated, but the basic fees are just higher then other countries.
posted by delmoi at 12:04 PM on December 1, 2009
Higher costs then other countries are a big factor in our healthcare costs though. Here's an Ezra Klein article about it. Obviously it's complicated, but the basic fees are just higher then other countries.
posted by delmoi at 12:04 PM on December 1, 2009
7. An avoidance of cheap, proven, off-the-shelf packages in favour of costly, unproven, custom built software; or worse the tailoring of a standard proven package.
Tailoring an existing proven solution is, like, one of the best ways to approach software development. A core product exists and is well tested - you add what you need to make it work even better for you. How is this not the best of both worlds?
posted by cbecker333 at 12:07 PM on December 1, 2009
Tailoring an existing proven solution is, like, one of the best ways to approach software development. A core product exists and is well tested - you add what you need to make it work even better for you. How is this not the best of both worlds?
posted by cbecker333 at 12:07 PM on December 1, 2009
Hospital systems, clinic management systems, systems that while "designed" by doctors wwere implemented by the lowest bid programming contractor with no data and/or usability designer/architect in-place.
This, a million times over. I work for a firm that has worked with hospitals and even developed a large-scale piece of software to document where medical supplies need to go in 3rd world countries. The software is successful because it was done right the first time, but the general hospital we were working with left us because "we were charging them too much for things they could do."
This is the same hospital that outsources their networking security and the entire pharmacy was locked out of their meds in the maturnity ward for two days.
Hospitals are losing money because they are paying software engineers that don't actually know what they're doing and have no experience or user experience experts on hand, and it takes years of shoddy research and even worse implementation to put something out. Then there are so many revisions and scope-of-work changes.. it just becomes a huge headache.
While yes, someone needs to make a generic, unbranded, universal utility, the time and effort it would take to nail it enough to make it worthwhile is something the people with the right experience don't feel like risking.
Even if that software was available, you're relying on the hope that someone high enough at that hospital will take it seriously.. and all-too often, companies think they need specifically-tailored solutions for their "specially-tailored" facilities.
posted by june made him a gemini at 12:07 PM on December 1, 2009
This, a million times over. I work for a firm that has worked with hospitals and even developed a large-scale piece of software to document where medical supplies need to go in 3rd world countries. The software is successful because it was done right the first time, but the general hospital we were working with left us because "we were charging them too much for things they could do."
This is the same hospital that outsources their networking security and the entire pharmacy was locked out of their meds in the maturnity ward for two days.
Hospitals are losing money because they are paying software engineers that don't actually know what they're doing and have no experience or user experience experts on hand, and it takes years of shoddy research and even worse implementation to put something out. Then there are so many revisions and scope-of-work changes.. it just becomes a huge headache.
While yes, someone needs to make a generic, unbranded, universal utility, the time and effort it would take to nail it enough to make it worthwhile is something the people with the right experience don't feel like risking.
Even if that software was available, you're relying on the hope that someone high enough at that hospital will take it seriously.. and all-too often, companies think they need specifically-tailored solutions for their "specially-tailored" facilities.
posted by june made him a gemini at 12:07 PM on December 1, 2009
I should point out that not all off-the-shelf products can easily be tailored or modified, but if it was originally designed with this flexibility in mind that is the ideal scenario.
posted by cbecker333 at 12:08 PM on December 1, 2009 [1 favorite]
posted by cbecker333 at 12:08 PM on December 1, 2009 [1 favorite]
You know, if you support more efficient health care records, etc, you might as well support the national ID card thingymajig. It would seriously help if there was a centralized data resource that had more than just your social security number on it. You know, like age, date of birth, ethnicity, weight, height, hair color, eye color, address, phone number, email address, insurance information, etc, etc, etc, all in one place. Then you wouldn't have to fill out any forms when being admitted to the hospital, just swipe the magnetic strip on the back of your ID through the card reader and all that information is provided to the hospital and they don't have to do that pre-screening check or anything, just assign you a bed and wait for a doctor to stroll around with his nifty little touch screen computer and tricorder and take a reading, tell you to take 2 asprin and call him in the morning and you are on your way. It would be so much easier to manage this data if there was a stardardized mandated system. It really would make it so much easier.
/sarcasm
This is where we are going to have a long hard battle. Standardizing medical records is seriously going to be the first step towards standardizing tracking information about citizens of this country. When you are mandated by law to have health insurance, you will have to be in the system. Have to. No if's and's or buts. I'm not trying to sound paranoid about BIG BROTHER here. I'm just pointing that this fight is a very old one and it's going to get much more heated soon.
I wonder if just making everybodies information public would solve the problem? Just take away any sense of secrecy or privacy. Everyone is a celebrity. No one gets to not know anything they want about anyone else. Maybe I've been reading too much Rudy Rucker...
posted by daq at 12:09 PM on December 1, 2009
/sarcasm
This is where we are going to have a long hard battle. Standardizing medical records is seriously going to be the first step towards standardizing tracking information about citizens of this country. When you are mandated by law to have health insurance, you will have to be in the system. Have to. No if's and's or buts. I'm not trying to sound paranoid about BIG BROTHER here. I'm just pointing that this fight is a very old one and it's going to get much more heated soon.
I wonder if just making everybodies information public would solve the problem? Just take away any sense of secrecy or privacy. Everyone is a celebrity. No one gets to not know anything they want about anyone else. Maybe I've been reading too much Rudy Rucker...
posted by daq at 12:09 PM on December 1, 2009
Systems where, if you press the "TAB" key to move from one field to another (a standard keyboarding mechanism for decades) your focus jumps randomly, never the same way twice - making quick keyboard navigation impossible.
Haha, that sounds like a MS Access form, or some other MS GUI Designed form (like ASP). The tab goes to the through the fields in the order they are added to the form (and it actually will go the same way each time for each field, but that can be hard to notice)
The thing is, you can change the tab order, and it only takes a few minutes. The software could have been fixed. The developers didn't know they could do that, because they were idiots.
The thing is, computer technology should be used to improve outcomes, not reduce costs. Almost 100,000 people die in the U.S. every year due to medical error or illness caught at hospitals. Obviously computers can't help with infections, but they can certainly be used as checklists and to get the right information and help make the right decisions.
Lots of people have this romantic idea of doctors as independent scientists using their smarts to figure out exactly what to do, but the fact is that they're not all House, and doctors fuck up a lot and kill and maim a huge number of people ever year.
There was this study showing a simple paper checklist could reduce medical error a huge amount, imagine having a computerize checklist for every condition, as well as diagnosis -- backed analysis of super-detailed statistics captured with the same devices used read the checklists.
It wouldn't save administrative time, but it would vastly save money in terms of reduced costs from not having people get sick due to medical error.
posted by delmoi at 12:29 PM on December 1, 2009 [2 favorites]
Haha, that sounds like a MS Access form, or some other MS GUI Designed form (like ASP). The tab goes to the through the fields in the order they are added to the form (and it actually will go the same way each time for each field, but that can be hard to notice)
The thing is, you can change the tab order, and it only takes a few minutes. The software could have been fixed. The developers didn't know they could do that, because they were idiots.
The thing is, computer technology should be used to improve outcomes, not reduce costs. Almost 100,000 people die in the U.S. every year due to medical error or illness caught at hospitals. Obviously computers can't help with infections, but they can certainly be used as checklists and to get the right information and help make the right decisions.
Lots of people have this romantic idea of doctors as independent scientists using their smarts to figure out exactly what to do, but the fact is that they're not all House, and doctors fuck up a lot and kill and maim a huge number of people ever year.
There was this study showing a simple paper checklist could reduce medical error a huge amount, imagine having a computerize checklist for every condition, as well as diagnosis -- backed analysis of super-detailed statistics captured with the same devices used read the checklists.
It wouldn't save administrative time, but it would vastly save money in terms of reduced costs from not having people get sick due to medical error.
posted by delmoi at 12:29 PM on December 1, 2009 [2 favorites]
This is where we are going to have a long hard battle. Standardizing medical records is seriously going to be the first step towards standardizing tracking information about citizens of this country.
If you don't think the U.S. government doesn’t have a 'standardized' method for tracking everyone, you're delusional.
Just look at what homeland security already knows about your travel records Given they already know everywhere you travel, what good would knowing about your hemorrhoids be for them?
As far as a national ID, they already have Real ID. All driver's licenses are standardized and tracked nationally. What difference does it make if we have 50 interoperable national ids vs. 1 single issuer?
I mean, being willing to sacrifice tens of thousands of lives due to medical errors that could be avoided with better IT because about the government getting a power it already has is ridiculous.
posted by delmoi at 12:35 PM on December 1, 2009
If you don't think the U.S. government doesn’t have a 'standardized' method for tracking everyone, you're delusional.
Just look at what homeland security already knows about your travel records Given they already know everywhere you travel, what good would knowing about your hemorrhoids be for them?
As far as a national ID, they already have Real ID. All driver's licenses are standardized and tracked nationally. What difference does it make if we have 50 interoperable national ids vs. 1 single issuer?
I mean, being willing to sacrifice tens of thousands of lives due to medical errors that could be avoided with better IT because about the government getting a power it already has is ridiculous.
posted by delmoi at 12:35 PM on December 1, 2009
It will help the bill show up faster, but it will also allow doctors and nurses to get your medical records quicker, and be able to look up relevant information on your condition quicker, and they'll be able to use expert systems to aide diagnosis as well.
Does that make the system more efficient though? It's not as if medical professionals were forced to sit with their thumbs up their assholes waiting for records, the latest issue of JAMA, or the clinical tests which offer more bang for the buck than fragile expert systems.
The thing is, computer technology should be used to improve outcomes, not reduce costs. Almost 100,000 people die in the U.S. every year due to medical error or illness caught at hospitals. Obviously computers can't help with infections, but they can certainly be used as checklists and to get the right information and help make the right decisions.
Certainly. But what you describe is a human performance problem, not necessarily a computer interface problem. Medical error because people don't follow checklists and procedures (or follow them blindly based on bad information) isn't a problem that can be fixed by moving the checklist and bullet points onto a tablet computer.
posted by KirkJobSluder at 12:46 PM on December 1, 2009
Does that make the system more efficient though? It's not as if medical professionals were forced to sit with their thumbs up their assholes waiting for records, the latest issue of JAMA, or the clinical tests which offer more bang for the buck than fragile expert systems.
The thing is, computer technology should be used to improve outcomes, not reduce costs. Almost 100,000 people die in the U.S. every year due to medical error or illness caught at hospitals. Obviously computers can't help with infections, but they can certainly be used as checklists and to get the right information and help make the right decisions.
Certainly. But what you describe is a human performance problem, not necessarily a computer interface problem. Medical error because people don't follow checklists and procedures (or follow them blindly based on bad information) isn't a problem that can be fixed by moving the checklist and bullet points onto a tablet computer.
posted by KirkJobSluder at 12:46 PM on December 1, 2009
A little anecdote:
I'm at a deposition of an orthopedic surgeon and he wants to use the hospital and clinic's integrated record system. The IT department leaves a laptop on the conference room table for the doctor to use.
The doctor can't seem to get logged in to the system so he calls for IT support. After about 15 minutes, the IT person comes in and logs the doc in. He then leaves. With access to the records, the doc now attempts to call up the imaging studies which are accessed through a separate application which the doc promptly manages to freeze as it attempts to attach to the data base housing the imaging studies.
This requires a reboot of the laptop which requires the doc to relog into the system which he can't do. The IT support then reappears (after a 15 minute wait) to relog the doc and start the imaging app. When asked by the doc, why the imaging app hung, he replied that sometimes it just does that and that one has to be patient and just keep trying to get it to run.
A couple of observations here:
First, the doctor obviously had insufficient training to properly utilize the tools.
Second, the IT person may have been being kind, but I really think he was sincere in his explanation of why the imaging app was difficult to use.
Finally, throughout the deposition, the doctor ended up referring to the hard copies of the records that we supplied him with due to the fact that the app for the records made it hard to get to a particular record in a quick fashion.
Better training and better apps would both seem to be necessary.
posted by mygoditsbob at 12:48 PM on December 1, 2009
I'm at a deposition of an orthopedic surgeon and he wants to use the hospital and clinic's integrated record system. The IT department leaves a laptop on the conference room table for the doctor to use.
The doctor can't seem to get logged in to the system so he calls for IT support. After about 15 minutes, the IT person comes in and logs the doc in. He then leaves. With access to the records, the doc now attempts to call up the imaging studies which are accessed through a separate application which the doc promptly manages to freeze as it attempts to attach to the data base housing the imaging studies.
This requires a reboot of the laptop which requires the doc to relog into the system which he can't do. The IT support then reappears (after a 15 minute wait) to relog the doc and start the imaging app. When asked by the doc, why the imaging app hung, he replied that sometimes it just does that and that one has to be patient and just keep trying to get it to run.
A couple of observations here:
First, the doctor obviously had insufficient training to properly utilize the tools.
Second, the IT person may have been being kind, but I really think he was sincere in his explanation of why the imaging app was difficult to use.
Finally, throughout the deposition, the doctor ended up referring to the hard copies of the records that we supplied him with due to the fact that the app for the records made it hard to get to a particular record in a quick fashion.
Better training and better apps would both seem to be necessary.
posted by mygoditsbob at 12:48 PM on December 1, 2009
I'm not at all saying that we shouldn't endeavor to develop better HCI, including computer-aided visualization and cognition. I'm pointing out that as long as the process hinges on human beings performing interviews with patients, performing medical procedures, and reviewing medical data, throwing IT at the problem won't fix either the inefficiencies or the errors.
posted by KirkJobSluder at 12:53 PM on December 1, 2009 [1 favorite]
posted by KirkJobSluder at 12:53 PM on December 1, 2009 [1 favorite]
Holy moly. That VistA thing. Its written in MUMPS. That light at the end of the tunnel? Yeah, it's a train.
posted by moonbiter at 12:57 PM on December 1, 2009 [5 favorites]
posted by moonbiter at 12:57 PM on December 1, 2009 [5 favorites]
Because you know, we have a simple and elegant solution to an entire class of medical errors that uses a permanent marker, and people still get it wrong.
posted by KirkJobSluder at 1:06 PM on December 1, 2009
posted by KirkJobSluder at 1:06 PM on December 1, 2009
Medical error because people don't follow checklists and procedures (or follow them blindly based on bad information) isn't a problem that can be fixed by moving the checklist and bullet points onto a tablet computer.
Except you can check to see if the doctor actually followed it, and score them based on their following of procedure.
Following a checklist based on bad information might not be very helpful, but it seems that free-balling it on bad information would be just as problematic, if not worse.
posted by delmoi at 1:16 PM on December 1, 2009
Except you can check to see if the doctor actually followed it, and score them based on their following of procedure.
Following a checklist based on bad information might not be very helpful, but it seems that free-balling it on bad information would be just as problematic, if not worse.
posted by delmoi at 1:16 PM on December 1, 2009
It's a really, really hard problem and, though it is real, it's incompetence rather than malice that causes these bad designs.
I don't know about "really, really" but yes, designing a good UI takes skill and effort no doubt.
The thing about medical software that I've noticed, having worked in a few hospitals in my IT career, is that it seems to all be designed by monkeys who learned VB from a mail order course.
I mean, one screen {tab} moves to the next field, on the next {tab} moves the page down.
Alt-P means "Print this form" when on the patient history screen, but mean "Auto fill this form" when on the patient transfer screen.
And hell, on the surgical screen, you can't use the arrow keys at all, you're going to have to click in the entry box with the mouse.
These are not caused by the hospital not knowing what it wants, or not getting nurses involved soon enough in the design process, these are just lazy, user-unfriendly, productivity killing screw-ups.
And don't get me started on the craptastic backends these things come with.
Install a hotfix on your server? Backend is borked. Job queue hanging every 27 hours? Sure, just create a batch file to restart the process.
Sorry, no, you can't virtualize the machine, that will void your support contract.
Which is, of course, not to say that other enterprise software isn't full of the same problems, but for some reason, medical software inhabits a deeper level of UI hell.
Maybe it's because of the limited monopoly market, maybe it's because it's all sold via consultants taking hospital administrators on golf junkets, I dunno, but I'm certainly not surprised at the conclusions of the report.
posted by madajb at 1:32 PM on December 1, 2009 [1 favorite]
I don't know about "really, really" but yes, designing a good UI takes skill and effort no doubt.
The thing about medical software that I've noticed, having worked in a few hospitals in my IT career, is that it seems to all be designed by monkeys who learned VB from a mail order course.
I mean, one screen {tab} moves to the next field, on the next {tab} moves the page down.
Alt-P means "Print this form" when on the patient history screen, but mean "Auto fill this form" when on the patient transfer screen.
And hell, on the surgical screen, you can't use the arrow keys at all, you're going to have to click in the entry box with the mouse.
These are not caused by the hospital not knowing what it wants, or not getting nurses involved soon enough in the design process, these are just lazy, user-unfriendly, productivity killing screw-ups.
And don't get me started on the craptastic backends these things come with.
Install a hotfix on your server? Backend is borked. Job queue hanging every 27 hours? Sure, just create a batch file to restart the process.
Sorry, no, you can't virtualize the machine, that will void your support contract.
Which is, of course, not to say that other enterprise software isn't full of the same problems, but for some reason, medical software inhabits a deeper level of UI hell.
Maybe it's because of the limited monopoly market, maybe it's because it's all sold via consultants taking hospital administrators on golf junkets, I dunno, but I'm certainly not surprised at the conclusions of the report.
posted by madajb at 1:32 PM on December 1, 2009 [1 favorite]
emjaybee: Well if we had government-run healthcare, at least everyone would be using the same crappy IT setup. Which might in theory be reformable.
I wouldn't count on that. Canada's publicly funded health care system is best described as an interlocking set of ten provincial and three territorial health insurance plans. And of course with thirteen sets of bureaucracy there is little that they agree on completely, IT or otherwise. I know states are less powerful in the US than are our provinces, but still I can't imagine the different parties agreeing on a nationwide IT standard.
Take IT security for example. Is Common Criteria being uniformly implemented, or FIPS for encryption? Security standards like Common Criteria are expensive and complex to achieve, so it's often not done or done poorly. I don't think healthcare IT will be any less so.
posted by Hardcore Poser at 1:43 PM on December 1, 2009
I wouldn't count on that. Canada's publicly funded health care system is best described as an interlocking set of ten provincial and three territorial health insurance plans. And of course with thirteen sets of bureaucracy there is little that they agree on completely, IT or otherwise. I know states are less powerful in the US than are our provinces, but still I can't imagine the different parties agreeing on a nationwide IT standard.
Take IT security for example. Is Common Criteria being uniformly implemented, or FIPS for encryption? Security standards like Common Criteria are expensive and complex to achieve, so it's often not done or done poorly. I don't think healthcare IT will be any less so.
posted by Hardcore Poser at 1:43 PM on December 1, 2009
delmoi: Checklists as normally implemented are a human performance intervention. They depend on training and willingness to actually perform the procedure as prescribed, and administrative incentives/consequences for failing to follow procedure. Computerizing them is certainly a great idea, but just creating computer checklists isn't going to change the practice.
posted by KirkJobSluder at 1:45 PM on December 1, 2009
posted by KirkJobSluder at 1:45 PM on December 1, 2009
Holy Shit:
posted by geoff. at 1:46 PM on December 1, 2009 [4 favorites]
In M, the current date and time is contained in a special system variable, $H (for "HOROLOG"). The format is a pair of integers separated by a comma, e.g. "54321,12345" The first number is the number of days since December 31st, 1840, i.e. day number 1 is January 1st, 1841; the second is the number of seconds since midnight.I can't imagine why a language that would require you to count time from some arbitrary date in the middle of the 19th c. would produce horrible software.
When I decided on specifications for the date routine, I remembered reading of the oldest (one of the oldest?) U.S. citizen, a Civil War veteran, who was 121 years old at the time. Since I wanted to be able to represent dates in a Julian-type form so that age could be easily calculated and to be able to represent any birth date in the numeric range selected, I decided that a starting date in the early 1840s would be 'safe.' Since my algorithm worked most logically when every fourth year was a leap year, the first year was taken as 1841. The zero point was then December 30, 1840...
posted by geoff. at 1:46 PM on December 1, 2009 [4 favorites]
geoff. But most languages use a variant of the unix epoch.
posted by KirkJobSluder at 2:00 PM on December 1, 2009
posted by KirkJobSluder at 2:00 PM on December 1, 2009
It would seriously help if there was a centralized data resource that had more than just your social security number on it. You know, like age, date of birth, ethnicity, weight, height, hair color, eye color, address, phone number, email address, insurance information, etc, etc, etc, all in one place.
This is probably the way it's going to go. This is the way that administrators and businessmen and politicians tend to think. It grants control (and provides a contracting opportunity for the lucky winners!), so it's a natural way for them. It's not the only way.
The problem isn't that all data needs to be in one spot. The problem is that it needs to be easy to convey the data.
A smart card, a USB drive with an agreed-upon data format, or even a bar code standard could solve these problems. Medical records too.
Someone needs to implement a solution like this if people are going to own their data.
posted by weston at 2:05 PM on December 1, 2009
This is probably the way it's going to go. This is the way that administrators and businessmen and politicians tend to think. It grants control (and provides a contracting opportunity for the lucky winners!), so it's a natural way for them. It's not the only way.
The problem isn't that all data needs to be in one spot. The problem is that it needs to be easy to convey the data.
A smart card, a USB drive with an agreed-upon data format, or even a bar code standard could solve these problems. Medical records too.
Someone needs to implement a solution like this if people are going to own their data.
posted by weston at 2:05 PM on December 1, 2009
Well if we had government-run healthcare, at least everyone would be using the same crappy IT setup.
Everyone would probably be using VistA, which, from what I understand, is actually good as far as healthcare software goes.
posted by zsazsa at 2:13 PM on December 1, 2009
Everyone would probably be using VistA, which, from what I understand, is actually good as far as healthcare software goes.
posted by zsazsa at 2:13 PM on December 1, 2009
I can't imagine why a language that would require you to count time from some arbitrary date in the middle of the 19th c. would produce horrible software.
Why not? That's how most software works. You get an integer representing the number of seconds since midnight, Jan 1 1900, or 1970, or whatever. There are usually functions that will give you the calender date from that number.
posted by delmoi at 2:18 PM on December 1, 2009
Why not? That's how most software works. You get an integer representing the number of seconds since midnight, Jan 1 1900, or 1970, or whatever. There are usually functions that will give you the calender date from that number.
posted by delmoi at 2:18 PM on December 1, 2009
How else are they expected to keep track of what my name isn't, what is not wrong with me, and which medicines I ought not be administered?
posted by turgid dahlia at 2:26 PM on December 1, 2009
posted by turgid dahlia at 2:26 PM on December 1, 2009
I've seen the computer system they use in the local hospital. It looks like it was made in the 80s. I thought the mid-90s corporate software I use was bad. The nurses have to memorize hundreds of typed commands for every procedure and condition and it takes 3-4 times as long as handwriting. It predates the mouse.
On the other hand, I recently went to see a new doctor and she sat me down in her office and interviewed me while taking notes on her laptop in what looked like notepad. She then carried her laptop to the exam room, made more notes and wrote the scripts electronically to be called in to my pharmacy. It was quick, efficient, paperless, and seems like it would help with actually being able to access and read doctor notes later. It was just the first time I'd seen a doctor actively use technology. It was also the fastest trip I've had to the doctor in recent memory, without feeling like my care was neglected or I was being rushed.
posted by threeturtles at 2:26 PM on December 1, 2009
On the other hand, I recently went to see a new doctor and she sat me down in her office and interviewed me while taking notes on her laptop in what looked like notepad. She then carried her laptop to the exam room, made more notes and wrote the scripts electronically to be called in to my pharmacy. It was quick, efficient, paperless, and seems like it would help with actually being able to access and read doctor notes later. It was just the first time I'd seen a doctor actively use technology. It was also the fastest trip I've had to the doctor in recent memory, without feeling like my care was neglected or I was being rushed.
posted by threeturtles at 2:26 PM on December 1, 2009
I, tangentially, have a little experience with medical software. My previous job was with a small software company that made a web-based app for managing claim submissions between the provider and insurer. I was brought on to help develop/design the basic UI for the thing.
The original UI was created by the developers. Windows developers. Everything looked like a Win95-era conglomeration of buttons, fields and stock icons, with absolutely no real feel for work flow or usability. Well, not human usability. Work flow seemed to be determined not by how the end-user would do things but, rather, by how functions "logically" related to each other in the developer's minds. In point of fact, they had yet to actually test anything with users. Yet, every time I put together an organized workflow for a particular page, the firewalls went up and they started the choruses of "You can't do that in this software" or whatever canned excuse they had. There was a very real, very visceral objection to doing things differently.
And don't get me started on the discussions over the error messages their system threw at the users. Hell, even the devs had problems understanding half of them.
Eventually, things got better, once they got a better feel for what I was trying to do for them. But, man, that first year was rough-going. I can't imagine developing a complete medical management suite for a hospital system.
posted by Thorzdad at 2:29 PM on December 1, 2009 [1 favorite]
The original UI was created by the developers. Windows developers. Everything looked like a Win95-era conglomeration of buttons, fields and stock icons, with absolutely no real feel for work flow or usability. Well, not human usability. Work flow seemed to be determined not by how the end-user would do things but, rather, by how functions "logically" related to each other in the developer's minds. In point of fact, they had yet to actually test anything with users. Yet, every time I put together an organized workflow for a particular page, the firewalls went up and they started the choruses of "You can't do that in this software" or whatever canned excuse they had. There was a very real, very visceral objection to doing things differently.
And don't get me started on the discussions over the error messages their system threw at the users. Hell, even the devs had problems understanding half of them.
Eventually, things got better, once they got a better feel for what I was trying to do for them. But, man, that first year was rough-going. I can't imagine developing a complete medical management suite for a hospital system.
posted by Thorzdad at 2:29 PM on December 1, 2009 [1 favorite]
The problem isn't that all data needs to be in one spot. The problem is that it needs to be easy to convey the data.
A smart card, a USB drive with an agreed-upon data format, or even a bar code standard could solve these problems. Medical records too.
This makes me laugh because I work with "Protected Health Information" and that means that they had to disable all our USB ports at work so that we couldn't use USB drives to steal health information. It also makes our computers near useless, but it's all in the name of HIPPA. I like confidentiality as much as the next person or more, but ultimately privacy and technology are at odds with each other. Either you want everyone to have access to your health records or you want no one to have that information. I don't see how you can have both.
posted by threeturtles at 2:30 PM on December 1, 2009 [2 favorites]
A smart card, a USB drive with an agreed-upon data format, or even a bar code standard could solve these problems. Medical records too.
This makes me laugh because I work with "Protected Health Information" and that means that they had to disable all our USB ports at work so that we couldn't use USB drives to steal health information. It also makes our computers near useless, but it's all in the name of HIPPA. I like confidentiality as much as the next person or more, but ultimately privacy and technology are at odds with each other. Either you want everyone to have access to your health records or you want no one to have that information. I don't see how you can have both.
posted by threeturtles at 2:30 PM on December 1, 2009 [2 favorites]
There are usually functions that will give you the calender date from that number
Oh yeah of course. I guess I never thought about it.
posted by geoff. at 2:31 PM on December 1, 2009
Oh yeah of course. I guess I never thought about it.
posted by geoff. at 2:31 PM on December 1, 2009
Um... well... it's more complicated than that. Is anyone surprised? For one thing, there is more than one kind of "computers for hospitals."
For a while, I worked tech support for a medical supply company I shall not name. They provide and support the equipment for remote patient monitoring. Patients wear a little dealie which broadcasts their stats (heart rate, etc) wirelessly to a Solaris desktop computer.
The system is wicked expensive for the hospital, both the initial cost of the systems/equipment/installation and the cost of ongoing tech support.
However, it allows one person at the central nurse's station to monitor the vital signs of every patient on their floor from one bank of computer monitors. It also lets you set up remote telemetry labs, where three monitor monkeys in a bunker somewhere can monitor the vitals of every patient in the hospital.
Theoretically, the cost savings is in the reduced number of nurses needed on staff to monitor patients. But that's never really how it works out, so far as I know. Instead, it allows nurses to better budget their time, because you can sit at the station and catch up on your paperwork while monitoring your patients.
In other words, the savings wasn't in direct financial terms, but in other efficiencies (which are almost impossible to measure). And it allows for better monitoring of patients, and better response times for patient emergencies. I would argue that there are some things better than "saving money," and improved patient telemetry for the ER or NICU is one of those things.
But of course, I'm not one of the salespeople tasked with selling that bill of goods to the hospital administration. There is a pretty significant delta between "what the salesperson says" and "reality."
posted by ErikaB at 2:58 PM on December 1, 2009 [1 favorite]
For a while, I worked tech support for a medical supply company I shall not name. They provide and support the equipment for remote patient monitoring. Patients wear a little dealie which broadcasts their stats (heart rate, etc) wirelessly to a Solaris desktop computer.
The system is wicked expensive for the hospital, both the initial cost of the systems/equipment/installation and the cost of ongoing tech support.
However, it allows one person at the central nurse's station to monitor the vital signs of every patient on their floor from one bank of computer monitors. It also lets you set up remote telemetry labs, where three monitor monkeys in a bunker somewhere can monitor the vitals of every patient in the hospital.
Theoretically, the cost savings is in the reduced number of nurses needed on staff to monitor patients. But that's never really how it works out, so far as I know. Instead, it allows nurses to better budget their time, because you can sit at the station and catch up on your paperwork while monitoring your patients.
In other words, the savings wasn't in direct financial terms, but in other efficiencies (which are almost impossible to measure). And it allows for better monitoring of patients, and better response times for patient emergencies. I would argue that there are some things better than "saving money," and improved patient telemetry for the ER or NICU is one of those things.
But of course, I'm not one of the salespeople tasked with selling that bill of goods to the hospital administration. There is a pretty significant delta between "what the salesperson says" and "reality."
posted by ErikaB at 2:58 PM on December 1, 2009 [1 favorite]
I've seen the computer system they use in the local hospital. It looks like it was made in the 80s.
Not health care, but I once noticed on the entrancing and hypnotic How It's Made that whatever the industrial process we were watching was being controlled by a computer.
Specifically, an Apple II.
I can't imagine the depth of shit they're going to find themselves in when it finally breaks.
posted by ROU_Xenophobe at 3:17 PM on December 1, 2009 [2 favorites]
Not health care, but I once noticed on the entrancing and hypnotic How It's Made that whatever the industrial process we were watching was being controlled by a computer.
Specifically, an Apple II.
I can't imagine the depth of shit they're going to find themselves in when it finally breaks.
posted by ROU_Xenophobe at 3:17 PM on December 1, 2009 [2 favorites]
Why not? That's how most software works. You get an integer representing the number of seconds since midnight, Jan 1 1900, or 1970, or whatever. There are usually functions that will give you the calender date from that number.
For the systems that count from 1990-01-01, they typically consider 1900 as a leap year and get the rest of the math pretty screwed up.
The other problem with day + second offset is that it doesn't deal cleanly with timezones or DST and requires corner cases to handle computation that spans multiple days or crosses summer/winter time shifts. Seconds or microseconds past the epoch make much more sense.
The list of epoch dates from wikipedia includes Mumps' 1841 choice. NT's choice of 1601 is supposed to put it past the Gregorian correction, except that in the parts of the world it wasn't recognized until September 1752*.
Is everyone ready for 2038?
posted by autopilot at 3:22 PM on December 1, 2009 [1 favorite]
For the systems that count from 1990-01-01, they typically consider 1900 as a leap year and get the rest of the math pretty screwed up.
The other problem with day + second offset is that it doesn't deal cleanly with timezones or DST and requires corner cases to handle computation that spans multiple days or crosses summer/winter time shifts. Seconds or microseconds past the epoch make much more sense.
The list of epoch dates from wikipedia includes Mumps' 1841 choice. NT's choice of 1601 is supposed to put it past the Gregorian correction, except that in the parts of the world it wasn't recognized until September 1752*.
Is everyone ready for 2038?
posted by autopilot at 3:22 PM on December 1, 2009 [1 favorite]
I have a great deal of recent experience with this in my job. Let's just say it's not as simple as saying computers don't save money for hospitals. They can, if they're utilized well. Unfortunately, this becomes more and more challenging when dealing on the institutional level, and with doctors specifically. But computers aren't always about saving money. Sometimes they're meant to do tasks which are necessary but which are still expenditures.
posted by krinklyfig at 3:31 PM on December 1, 2009
posted by krinklyfig at 3:31 PM on December 1, 2009
A smart card, a USB drive with an agreed-upon data format, or even a bar code standard could solve these problems. Medical records too.
All these things exist, more or less. Well, the bar codes, smart cards, that type of thing. The input/output is really not the issue, nor should it be standardized to one technology, because it doesn't need to be. All that is needed is a common interface, and we have that, well, sort of ...
posted by krinklyfig at 3:36 PM on December 1, 2009
All these things exist, more or less. Well, the bar codes, smart cards, that type of thing. The input/output is really not the issue, nor should it be standardized to one technology, because it doesn't need to be. All that is needed is a common interface, and we have that, well, sort of ...
posted by krinklyfig at 3:36 PM on December 1, 2009
Eventually, things got better, once they got a better feel for what I was trying to do for them. But, man, that first year was rough-going. I can't imagine developing a complete medical management suite for a hospital system.
A lot of them build on each others' ideas, so conceptually you already have an idea before you get started in most cases. A lot of the concepts surrounding this are starting to converge on common ideas. The better vendors pay attention to interface flexibility (because one size never fits all) as well as interoperability with other medical software.
posted by krinklyfig at 3:39 PM on December 1, 2009
A lot of them build on each others' ideas, so conceptually you already have an idea before you get started in most cases. A lot of the concepts surrounding this are starting to converge on common ideas. The better vendors pay attention to interface flexibility (because one size never fits all) as well as interoperability with other medical software.
posted by krinklyfig at 3:39 PM on December 1, 2009
We reached the point years ago where computer programs could interpret simple english syntax-- there's no reason these systems need to put nurses through fifteen context menus just to write "loose stools."
posted by benzenedream at 6:31 PM on December 1, 2009 [9 favorites]
> OPEN DOOR
You are in an exam room. There is a patient in front of you with a paper gown. He looks as if he has been waiting in the room for a long time.
> CHECK INSURANCE
He is carrying:
Blue Cross PPO
> LOOK STOOLS
The stools are loose.posted by benzenedream at 6:31 PM on December 1, 2009 [9 favorites]
I could write a book on this topic (but will try not to do so here in the comments). I agree with just about all of the (mostly negative) comments here and I speak from years of experience with computers in hospitals. Our department was an early adopter of computerized anesthesia records. The anesthesia record is a good candidate for computerization because much of it consists of recording vital signs and other numbers generated by patient monitors and most of the narrative notes that are entered are the same for each type of case. Furthermore in a big case that requires multiple lies, a number of drugs in addition to the 3 or 4 given during a routine anesthetic induction, perhaps interventions if the patient becomes unstable, and so on, it is difficult to keep up with a hand-written record. Without an automated record recording vitals and other information, we used to do our best to reconstruct the case from memory once things slowed down, and study after study has shown that a lot of inaccuracy is introduced that way. There is also the question of legibilty; trying to hastily jot down notes while in the middle of a busy case, often with no good place to write, does not lend itself to good penmanship. So with those sorts of concerns in mind our department purchased its first automated record keeping system circa 1992. It met with mixed reviews; there was some resistance to change, it was expensive (well into 6 figures to outfit all of our ORs), and it was quite primitive by today's standards; for example each OR had a dedicated dot-matrix printer rather than a central networked printer, as our OR was not wired for networking at that time. It ran a proprietary OS on computers with 80386 chips, which were kind of old and slow even then. On the other hand all of our subsequent systems run on Windows boxes so you have Windows-related crashes on top of any software bugs that come up. The biggest hassle, though was the fact that there is no standard for communication among medical devices. So we had to have another box that had to be set up to convert the output from each monitor (which varied from brand to brand and even within different models of the same brand of a given monitor; data outputs then were sometimes digital and sometimes analog) into a format the recorder could understand. People gradually warmed to automated records, though, and subsequent versions continue to improve. We are currently on our third generation and are looking for the next system to replace it with. People now prefer the automated records because they really do cut down on workload. However they still have their problems. For example, if the incorrect patients name or hospital number is entered on the record, you can't just change it back. It requires a phone call to the vendor (who maintains the central database) with detailed information, they have to correct the central database, and then you have to go back and reprint the corrected record. And the vendor can only do this during normal business hours. There is also a high level of IT support required; we have several IT employees whose primary focus is our system. Even if there is a relatively minor problem, we can't allow ourselves to become distracted from the patient lest we end up like the pilots of Eastern 401. And the problem of communications between the recordkeeping system and the differnt monitors is only slightly better (most monitors have digital outputs for data now). But in general this is one of the better implementations of medical informatics out there; even if it is just for one little niche of medicine.
Our administration has really bought into the concept of the paperless medical record, but it is turning out to be difficult to implement. Although many vendors claim to have a system that does everything, none of them do everything well (or in many cases even to the point of being usable). Some are better suited for lab results, others for radiology, others for order entry, and so on. As a result our hospital, like many others, has different systems for all of these functions and they communicate little if at all with each other. As a result a lot of data has to be entered by hand, increasing the workload. For example, our anesthesia record, although it exists in digital form, cannot be automatically entered into the rest of the chart, which is generated by software from a different vendor. So they are scanned in by hand which requires labor and delays the anesthesia record from being entered into the electronic record in a timely fashion. Furthermore, bar codes are used to let the medical record software know what kind of document is being scanned, but our software can only print barcodes vertically and the medical record software can only read them horizontally, so we have to put little barcode stickers on by hand when we print our records. These sorts of issues exist between all of the different systems that co-exist in our hospital. And there are numerous examples of systems that were purchased but never could be made to work as needed and so the hardware and software just sat around gathering dust until it was eventually thrown out. For example, although I like our anesthesia recordkeeping system, the module for the nurses to document the patient's stay in the recovery room is unwieldy enough that it has never been used in my part of the hospital. There are workstations set up and ready to go, but the nurses still do their charting on paper. And don't get me started on passwords. Each of these systems requires a password and since our IT department requires a new password every so often it is nearly impossible to keep them all synchronized. If it is a system I only rarely need to access, I have generally long forgotten my password and/or it has expired anyway, so I have to call the help desk and get it reset each time I log on-a waste of time for both of us.
So although electronic medical records have a lot of potential, there is still a long way to go. A good start would be as some have suggested above to standardize communications protocols for medical devices and software. But the equipment also has to be exceedingly robust, both physically (when you are rushing an unstable patient down the hall you tend to bang into things regardless of how fragile they may be) and in terms of minimizing bugs and downtime (we have elaborate downtime procedures to follow every time there is a software or hardware upgrade and it can be a pain). There was an article I read some time ago (probably linked here, but I can't find it) that described the software design team at NASA as being unique. They work regular hours, are very meticulous about everything, especially documentation, and they rigorously test the software after every change, however minor, looking for unwanted behavior. The result is some of the most dependable software ever written. Until makers of medical software take a similar approach, I think it is unlikely that it will reach its full potential.
posted by TedW at 7:28 PM on December 1, 2009 [4 favorites]
Our administration has really bought into the concept of the paperless medical record, but it is turning out to be difficult to implement. Although many vendors claim to have a system that does everything, none of them do everything well (or in many cases even to the point of being usable). Some are better suited for lab results, others for radiology, others for order entry, and so on. As a result our hospital, like many others, has different systems for all of these functions and they communicate little if at all with each other. As a result a lot of data has to be entered by hand, increasing the workload. For example, our anesthesia record, although it exists in digital form, cannot be automatically entered into the rest of the chart, which is generated by software from a different vendor. So they are scanned in by hand which requires labor and delays the anesthesia record from being entered into the electronic record in a timely fashion. Furthermore, bar codes are used to let the medical record software know what kind of document is being scanned, but our software can only print barcodes vertically and the medical record software can only read them horizontally, so we have to put little barcode stickers on by hand when we print our records. These sorts of issues exist between all of the different systems that co-exist in our hospital. And there are numerous examples of systems that were purchased but never could be made to work as needed and so the hardware and software just sat around gathering dust until it was eventually thrown out. For example, although I like our anesthesia recordkeeping system, the module for the nurses to document the patient's stay in the recovery room is unwieldy enough that it has never been used in my part of the hospital. There are workstations set up and ready to go, but the nurses still do their charting on paper. And don't get me started on passwords. Each of these systems requires a password and since our IT department requires a new password every so often it is nearly impossible to keep them all synchronized. If it is a system I only rarely need to access, I have generally long forgotten my password and/or it has expired anyway, so I have to call the help desk and get it reset each time I log on-a waste of time for both of us.
So although electronic medical records have a lot of potential, there is still a long way to go. A good start would be as some have suggested above to standardize communications protocols for medical devices and software. But the equipment also has to be exceedingly robust, both physically (when you are rushing an unstable patient down the hall you tend to bang into things regardless of how fragile they may be) and in terms of minimizing bugs and downtime (we have elaborate downtime procedures to follow every time there is a software or hardware upgrade and it can be a pain). There was an article I read some time ago (probably linked here, but I can't find it) that described the software design team at NASA as being unique. They work regular hours, are very meticulous about everything, especially documentation, and they rigorously test the software after every change, however minor, looking for unwanted behavior. The result is some of the most dependable software ever written. Until makers of medical software take a similar approach, I think it is unlikely that it will reach its full potential.
posted by TedW at 7:28 PM on December 1, 2009 [4 favorites]
geoff- that is hardly the worst wart in MUMPS. MUMPS has a goto-with-offset command. So you can have something like this
myLabel: do some stuff
do some other stuff
do even more stuff
$$someProcedure: goto myLabel+2
and that goto jumps to the "do even more stuff" line- the line pointed to by myLabel, plus two more lines down. So... if you're fixing a bug near myLabel, you can't change the number of lines between "do some stuff" and "do even more stuff" without changing the meaning of $$someProcedure. You have to be extremely careful when you're maintaining a legacy codebase full of that crap.
I worked on EMR software; my responsibilities included ensuring the integrity of a patient's code status (e.g. "Do Not Rescuscitate" orders, etc.). The impossibility of unit tests and the absolutely critical nature of the correctness of this functionality made that job the most stressful I've ever had, and I'm much healthier for having left it.
----------
That said, one of the biggest benefits of an EMR hasn't been mentioned yet in this thread, and it's one that you don't accrue if you don't have the right systems in place. CPOE (Computer physician order entry), where doctors enter their own orders, means that doctors (that comply!) enter their orders directly into the computer, instead of the brain-dead game of telephone that doctors, nurses, and pharmacists normally do with paper transcriptions of orders.
With computer order entry, ideally done by the physician originating the order, you can really cut down on medication errors, which are a serious problem in hospitals. Even when CPOE is in place, though, physicians often choose to go the paper route because they see entering orders into the computer as one more hoop to jump through, and they're much more used to the paper world.
posted by a snickering nuthatch at 7:40 PM on December 1, 2009 [2 favorites]
myLabel: do some stuff
do some other stuff
do even more stuff
$$someProcedure: goto myLabel+2
and that goto jumps to the "do even more stuff" line- the line pointed to by myLabel, plus two more lines down. So... if you're fixing a bug near myLabel, you can't change the number of lines between "do some stuff" and "do even more stuff" without changing the meaning of $$someProcedure. You have to be extremely careful when you're maintaining a legacy codebase full of that crap.
I worked on EMR software; my responsibilities included ensuring the integrity of a patient's code status (e.g. "Do Not Rescuscitate" orders, etc.). The impossibility of unit tests and the absolutely critical nature of the correctness of this functionality made that job the most stressful I've ever had, and I'm much healthier for having left it.
----------
That said, one of the biggest benefits of an EMR hasn't been mentioned yet in this thread, and it's one that you don't accrue if you don't have the right systems in place. CPOE (Computer physician order entry), where doctors enter their own orders, means that doctors (that comply!) enter their orders directly into the computer, instead of the brain-dead game of telephone that doctors, nurses, and pharmacists normally do with paper transcriptions of orders.
With computer order entry, ideally done by the physician originating the order, you can really cut down on medication errors, which are a serious problem in hospitals. Even when CPOE is in place, though, physicians often choose to go the paper route because they see entering orders into the computer as one more hoop to jump through, and they're much more used to the paper world.
posted by a snickering nuthatch at 7:40 PM on December 1, 2009 [2 favorites]
If everyone would just learn the keyboard shortcuts... seriously.
posted by Lukenlogs at 9:04 PM on December 1, 2009
posted by Lukenlogs at 9:04 PM on December 1, 2009
Based on the conclusion, it looks like computerization costs are included in administrative costs in the figures used. So wouldn't it be just as accurate to say that computerization more or less pays for itself and leads to minor improvements in quality of care?
posted by nathan v at 9:49 PM on December 1, 2009 [2 favorites]
posted by nathan v at 9:49 PM on December 1, 2009 [2 favorites]
I worked for a small startup from about 1999 to 2003 that tried to bite off a much smaller problem. We created a web based software system for small physician practices (~10 providers). We were way off base on our initial ideas of what would be practical, but had a small, nimble team of programmers (eventually) who fairly quickly homed in on what was needed. Starting with an EMR product, we quickly branched out into a total practice management system, including scheduling, billing, charting, test orders, Rx, and support for using a system of templates to let the physician control the whole thing during the patient exam on a wireless handheld. The end result was that when the system worked the physicians spent more time with patients and almost no time doing paperwork. The main drawback is that a physician office has no real IT staff, and the cost for fast mission critical internet connectivity to our server made our business model difficult, unless we put the server in the physician office, but then we needed it support at their location.
We learned a lot while working on this some of which I think applies to hospital systems. First, from a business perspective, you are climbing over the burned and smoking bodies of your predecessors in medical informatics just to get to your market. By this, I mean most of the VCs, doctors, etc... have all been involved with at least one failed project. These are usually people who consider themselves to be smart (most doctors seem to believe that medical school gifts them with above average intellect and the ability to make decisions in every field they come in contact with, no matter the depth of education or experience required to succeed in that field). Therefore it becomes difficult to sell them on backing a startup in a field where they've already failed. Second, most providers have experienced overhype on an existing medical system that was supposed to make their life easier but markedly did not. Usually the main problem here was that the system was prescriptive or uncustomizable and didn't fit in with their process. Where systems were geared toward providers, and training was available to allow them to maximize their results, usually there was a piece missing which required staff to enter data into multiple other systems, or there were issues with the interface for bulk data entry (which is usually heads down typing, get the tab order right, provide audio cues, etc...). So providers were extremely resistant to any kind of training unless the ROI could be explained to them in a very quick sales pitch. Which leads to the third thing; when selling to physicians, you are competing with the very obtrusive sales and marketing departments of pharmaceutical companies. You have to go above and beyond to get their attention and keep it. While you are working on these problems, much bigger companies are announcing initiatives that are supposedly the next big thing, and then delivering a big pile of unusable shit. Unfortunately, when a fortune 500 company announces a product in your space, people assume they are going to do a better job than an underfunded startup. There is no more knowledge retention or sense of history in the medical software industry than in the software industry as a whole unfortunately. Because of these and a host of other reasons, I think an outside company with a market driven approach has a really hard time moving into a space dominated by custom in-house solutions, which have their own issues.
There are and have been ISO/ANSI approved interoperability standards for patient health data for a long time, but that doesn't make trying to transfer huge chunks of heterogenous data between programs seamless or easy.
I feel that hospital/medical informatics is one of the most complicated domains for an industry that has already demonstrated an ability to fail at much simpler tasks (inventory systems for example, which would just be a subset of an all encompassing hospital system). It wouldn't surprise me to find that most in-house development comes in way over budget or not at all (requiring a write off and hasty purchase of another system). The holy grail is a system that fits the needs of most users, reduces errors, allows data collection for clinical trials, and gives the physicians more time with their patients. I think it's possible, but it's by no means an easy problem. I don't think there's a way to go back to paper records.
posted by BrotherCaine at 12:01 AM on December 2, 2009 [4 favorites]
We learned a lot while working on this some of which I think applies to hospital systems. First, from a business perspective, you are climbing over the burned and smoking bodies of your predecessors in medical informatics just to get to your market. By this, I mean most of the VCs, doctors, etc... have all been involved with at least one failed project. These are usually people who consider themselves to be smart (most doctors seem to believe that medical school gifts them with above average intellect and the ability to make decisions in every field they come in contact with, no matter the depth of education or experience required to succeed in that field). Therefore it becomes difficult to sell them on backing a startup in a field where they've already failed. Second, most providers have experienced overhype on an existing medical system that was supposed to make their life easier but markedly did not. Usually the main problem here was that the system was prescriptive or uncustomizable and didn't fit in with their process. Where systems were geared toward providers, and training was available to allow them to maximize their results, usually there was a piece missing which required staff to enter data into multiple other systems, or there were issues with the interface for bulk data entry (which is usually heads down typing, get the tab order right, provide audio cues, etc...). So providers were extremely resistant to any kind of training unless the ROI could be explained to them in a very quick sales pitch. Which leads to the third thing; when selling to physicians, you are competing with the very obtrusive sales and marketing departments of pharmaceutical companies. You have to go above and beyond to get their attention and keep it. While you are working on these problems, much bigger companies are announcing initiatives that are supposedly the next big thing, and then delivering a big pile of unusable shit. Unfortunately, when a fortune 500 company announces a product in your space, people assume they are going to do a better job than an underfunded startup. There is no more knowledge retention or sense of history in the medical software industry than in the software industry as a whole unfortunately. Because of these and a host of other reasons, I think an outside company with a market driven approach has a really hard time moving into a space dominated by custom in-house solutions, which have their own issues.
There are and have been ISO/ANSI approved interoperability standards for patient health data for a long time, but that doesn't make trying to transfer huge chunks of heterogenous data between programs seamless or easy.
I feel that hospital/medical informatics is one of the most complicated domains for an industry that has already demonstrated an ability to fail at much simpler tasks (inventory systems for example, which would just be a subset of an all encompassing hospital system). It wouldn't surprise me to find that most in-house development comes in way over budget or not at all (requiring a write off and hasty purchase of another system). The holy grail is a system that fits the needs of most users, reduces errors, allows data collection for clinical trials, and gives the physicians more time with their patients. I think it's possible, but it's by no means an easy problem. I don't think there's a way to go back to paper records.
posted by BrotherCaine at 12:01 AM on December 2, 2009 [4 favorites]
That 1st paragraph should have ended: 'but then we needed IT support at their location.'
posted by BrotherCaine at 12:31 AM on December 2, 2009
posted by BrotherCaine at 12:31 AM on December 2, 2009
Specifically, an Apple II.
My dad was an engineer at a big gov't lab, and three or four years back, there was an issue with a testing system's automation going belly up. It was a custom program coded on a Commodore 64. In assembler. It just worked, and was only used once or twice a year, and no-one thought much about it until it broke.
Someone had to track down a replacement disk drive on ebay, and then re-enter the code, by hand. (the source code was printed out in a binder next to the system, or they would have been truly hosed.)
The good news is, management has a replacement solution! A C=64 emulator on Linux.
posted by Slap*Happy at 7:56 AM on December 2, 2009 [4 favorites]
My dad was an engineer at a big gov't lab, and three or four years back, there was an issue with a testing system's automation going belly up. It was a custom program coded on a Commodore 64. In assembler. It just worked, and was only used once or twice a year, and no-one thought much about it until it broke.
Someone had to track down a replacement disk drive on ebay, and then re-enter the code, by hand. (the source code was printed out in a binder next to the system, or they would have been truly hosed.)
The good news is, management has a replacement solution! A C=64 emulator on Linux.
posted by Slap*Happy at 7:56 AM on December 2, 2009 [4 favorites]
Can Cleveland Clinic Be A Model For Digital Medicine?
posted by ericb at 10:20 AM on December 2, 2009
posted by ericb at 10:20 AM on December 2, 2009
« Older The Rehabilitation of Charles Johnson | The Ghost of Dickens' Christmas Past Newer »
This thread has been archived and is closed to new comments
posted by crayz at 9:46 AM on December 1, 2009 [28 favorites]