Slashdot Mirror


Harvard Says Computers Don't Save Hospitals Money

Lucas123 writes "Researchers at Harvard Medical School pored over survey data from more than 4,000 'wired' hospitals and determined that computerization of those facilities not only didn't save them a dime, but the technology didn't improve administrative efficiency either. The study also showed most of the IT systems were aimed at improving efficiency for hospital management — not doctors, nurses, and medical technicians. 'For 45 years or so, people have been claiming computers are going to save vast amounts of money and that the payoff was just around the corner. So the first thing we need to do is stop claiming things there's no evidence for. It's based on vaporware and [hasn't been] shown to exist or shown to be true,' said Dr. David Himmelstein, the study's lead author."

31 of 398 comments (clear)

  1. Transferability by oldhack · · Score: 5, Interesting

    Well, that's mouthful, but with electronic records you can at least switch doctors without having to take X-rays, tests, and other records again. No?

    --
    Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
    1. Re:Transferability by jma05 · · Score: 5, Informative

      Nope. The current Electronic Medical Record systems are not capable of exchanging information freely. There is no standard data format that everyone can exchange.
      There are a few standards that can package data, but they are not adequately specified for seamless interoperability.
      If you request records, they can print them out quickly for you though.

    2. Re:Transferability by AK+Marc · · Score: 5, Informative

      "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."

      The systems aren't put in help the doctors. They are put in by the non-medical managers to help their jobs. And they fail at that. A system designed for doctors with the goal of reducing error and improving care could work. But that's not what the systems are. They should start working now to have all records be electronic, X-rays, MRIs, personal history, etc. should be in formats that can be directly shared between doctors. Then processes and systems that are designed to help the medical care should be used to put that information to good use and let patience get improved care for a lower cost. But the systems are all billing systems first, and care second. And that's why they fail, and always will. Improving billing doesn't help care, and can often make it worse, as having a doctor or nurse putting in billing codes will only slow down the process.

    3. Re:Transferability by wisty · · Score: 4, Funny

      But what if it's in XML? It would inter-operate then.

      Or better still, a binary blob wrapped in XML. That would really make it easy to use!

    4. Re:Transferability by malkavian · · Score: 4, Insightful

      That's only part of the story. A LOT of systems are put in by heads of medical departments who engage directly with vendors, who tell them this system will cure all their ills and make the world a better place.
      They then buy in this system without asking anybody, and turn up at IT saying "We've bought this, put it in now please". Most hospital directorates back the clinicians (politics, gotta love it) and force IT to support this, even though it may duplicate information held elsewhere, or not be able to communicate with anything else. This crucifies efforts to create an enterprise class architecture.
      That being said, there are (in the NHS) many moves towards having everything standardised and digital (PACS, for example, works nicely; Dicom imagery across all hospitals connected to the NHS network. That's your XRay and MRI imagery right there).

      The problem is that very few places take IT seriously. It's viewed as a "wave a magic wand and things happen" discipline. Few want to hire system admins, let alone systems architects.
      And without people to actually work at integrating IT to the business, and without them having the remit to be able to affect business processes to help this symbiotic relationship take hold, then places will continue to scrabble ineffectually.
      If you're building a house, hire an architect. If you're building an IT system to prop up your business correctly, hire a systems architect.
      You could, of course, be happy with your IT system being the logical equivalent of a house built on mud with 22 windows on one side of it (never facing the sun) and no stairs to the upper floor that can be used.. But hey. You choose the path you walk.

    5. Re:Transferability by Bert64 · · Score: 3, Insightful

      There are clear benefits of the new system so I am confident to say that not only is it more efficient and will save money compared to a manual system, but it will also do the same compared to our other two clinic management packages - one is old and reliable (accessed through VT220 terminals or PCs running an emulation package) but very outdated and has no serious reporting or connectivity abilities, the other is 'modern' but buggy (crashes often), poorly written with a bad database schema that is totally space inefficient.

      I encounter situations like this a LOT... There will be an old system which is perfectly reliable, has been running for years and everyone can access it using whatever ancient terminals they have at their disposal. And it will usually be quite efficiently written because it runs on old hardware.
      Then some vendor will come along and blind management with a pretty graphical frontend, so they sign up and begin a transition to a new fancy looking graphical system which looked very pretty to the management types who quickly demoed it at the vendors offices...

      Of course, the vendors setup will have a very small data set, will be carefully set up to look as good as it can (they might not even let you touch it, just demo it themselves being very careful to avoid features which are known to be buggy), and the management types won't have tested it for very long (or at all) before they decided to buy, and these same management types won't have to use the resulting system once it's installed.

      Costs will rapidly escalate as you have to replace all your ancient terminals with new fancy equipment designed to handle the pretty graphics...
      You start loading your live data into the new system and find that when it has actual data in it, the new system is very slow and inefficient (but still looks nice!) because it was never tested under any realistic usage cases...
      You find that the original quoted hardware requirement was already insufficient (to make it look cheaper), and coupled with how slow the new system runs with real data you now have to increase your hardware budget...

      And once the system is finally installed and people start using it, you find that...
      While the app looks very pretty to management types, the people who actually have to use it find that the pretty graphics get in the way, and that the new app is far less usable than the old one.
      Your users were used to the old system, and don't like the new one, but this gets dismissed as "users dont like change" and blamed on them wether that's the case or not.
      Even new users who weren't used to the old system have trouble with the new one..
      When under actual load, the performance issues are even worse..
      The new system has lots of bugs, which the vendor expects you to adjust your working practice around rather than bothering to fix them...
      The new system also has a different workflow, which again the vendor expects you to adjust your working practice around.
      The new system brings with it a lot of unnecessary functionality which you don't need, and which will get abused by staff and external hackers alike (people didn't spend all day using facebook on green screen terminals, and didn't browse websites or view files which try to exploit your machine and own it)..
      As a result of the unnecessary functionality and new security risks, your administrative burden is now much higher (or the vendor convinces you otherwise, and you coast along for a while before you start having major problems).

      There's a lot to be said for keeping it simple!

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    6. Re:Transferability by AK+Marc · · Score: 4, Insightful

      Seriously - when are you slashdotters going to realize that part of the reason that nobody takes you seriously is because your analysis is so junior high level?

      I have a masters in business. When the people making the business decisions are divorced from the operations of the business, the item that helps them most may not help the company at all. Having seen the results of such decisions, I assure you the consequences are quite real, and because of poor managerial decisions.

    7. Re:Transferability by Grygus · · Score: 4, Insightful

      There's even more to be said for well-written software. What your post boils down to is, "poorly written software will not work as advertised." You're not going to get much argument on that here. The problem with the article (and your conclusion) is that they implicitly assume that all computer-based solutions are equal in quality. Since that isn't true, the analysis is ignoring a crucial component.

    8. Re:Transferability by arth1 · · Score: 3, Interesting

      I would like to see him try to do0 the mapping of a genome with paper and pencil.

      Yes, that would be as unbelievable as designing the Eiffel tower without a computer.
      The number of pieces in the Eiffel tower is in the same order of magnitude as the number of human genes (the bolts can be compared to base pairs). Clearly not doable.

      The old saying that "when all you have is a hammer, every problem starts looking like a nail" is true for computers too. We think of a computer solution first without even considering how something can be done other ways.

    9. Re:Transferability by MattSausage · · Score: 5, Interesting

      As a personal anecdote, computerized medical records most likely saved my father's life.

      He woke up in the middle of the night with unbearable pain in his abdomen, and when he didn't fight my mom about going to the hospital she knew it was serious. Five hours later and untold scans and prodding later (not to mention a significant amount of morphine) they determined a blood vessel leading to my father's colon had been blocked and basically part of his colon was dead or dying. Not having the facilities or expertise to handle the necessary surgery in my mid-size town of Owensboro, KY, they sent him to the University of Louisville Medical center telling us that basically, even done by the best surgeons in the business there is a 3 out of 4 chance he wouldnt' make it through surgery unless it was done in the next few hours. The trip to Louisville takes two hours. Following the ambulance we arrived in Louisville in an hour and a half, and he was in his room and being prepped when the doctors realized they didn't have any scans of his abdomen, the EMTs had left them behind in their rush to get us all there. Faxing them was the only option, and to do that they would have to get in touch with someone in Owensboro, convince them who they were, have them look up the records, and then get them to a fax machine that could handle the scans. It could take another hour.

      Except my mother (who, frankly, is the smartest person I know) insisted that she be given a copy of the CD with all the electronic scans and data the doctors had collected that morning. I thought the surgeon was going to kiss her. 20 minutes later my father is in surgery, and 5 hours after that (or so, it was a long day) he was back out and kept in ICU for two weeks before finally coming home. The doctor had said if he'd had to wait much longer chances would have shot up considerably that my father would have died. So, there is at least one example of how Electronic Medical Records did help a doctor save a life.

    10. Re:Transferability by Anonymous Coward · · Score: 4, Insightful

      Wow, I so just NEVER post anonymously but... I work at a healthcare company. Specifically, a Healthcare IT company. A very big one. One which develops an elctronic medical record, amongst other things, and is joined at the hip by several hospitals (we are a non-profit, they founded us)...

      Think about the flaws in how the government works, and you can start to grasp the problem. These institutions are setup, not to make a profit, but to do a job. To that end, they are going to do that job... come hell or high water. Its noble, its great, its a bureaucratic wet dream. They even budget the same way. In fact, last year is the FIRST TIME IN MY CAREER that when the end of the fiscal year rolled around, we did NOT hear talk of needing to use up the rest of our budget before we lose it.

      The problem is, that they create a whole bunch of fiefdoms, give them a mission, and then let them just creep that mission over the years. New servers, new disaster recovery plans. More security.

      Then we interact with government, and everyone has a stake in healthcare so...more regulations? Ever heard of hippa? No? Then you don't work in healthcare. We have yearly ethics classes, a whole department whose job is to police ethics internally. Increasing regulations seem to push us forward a lot.

      We are a mini-government. In many ways, I like it. How many other workplaces have an appeals process on disciplinary that can go all the way to an employee review board of randomly selected employees from other departments? We essentially have a jury system built into the company!

      And while governments have a feedback loop through voting, we do too. We have the board, which is chaired by big wig stakeholders, many of whom are hospital administrators and power player doctors. They allocate our budgets, they push agendas... which feed through us, and back to the hospitals, and their management.... which is our feedback loop.

      Its a labyrinth of departments, groups, teams, on down the line. An undulating stack of bureaucrats each moving forward, increasing his scope. Every department knows money is being wasted. However, its the other guy wasting it, because we are on a mission. We have to deliver this service right here, no matter what it costs.

      I wish I had time for more but, my group has a mission. Maybe later I can wax poetic about how "middle heavy" institutions like this grow. Remember those articles on the Gervais principal and how it relates to "The Office". Google it and reread it... realize that these organizations work under those dynamics, but remove the "organization falls apart" feedback loop. Imagine that model running its course for the 150 years that some hospitals have been around.

      Of course, theres been corruption too. We grumble about not even being able to take pens or free classes from vendors anymore. A whole host of new policies, all because a couple of guys were scamming contracts. These policies will never go away... only grow. (something which I have seen at 2 of the places that I have worked. In one they were fresh policies from a scandal that happened while I was there, and one from a scandal 20 years prior)

      THAT is where the problem is. This constant slow creep of policies, regulations, departments.

  2. Don't just computerize the process by WuphonsReach · · Score: 4, Insightful

    There's an old saw we had back in the 90s at UPS.

    Don't just computerize a process (or blindly apply technology to replicate an existing process) and expect to see savings.

    --
    Wolde you bothe eate your cake, and have your cake?
  3. I work in a major hospital by Anonymous Coward · · Score: 4, Interesting

    And have significant responsibilities for patient care and management. Computers have made my life much easier. With electronic charting I can follow all of my patients directly from a terminal that I carry with me. The charting software we have includes basic spreadsheet and summary functions that are highly customizable. I am able to track trends and make decisions for my patients based on sight and intuition rather than having to sort through paper charts and bad handwriting. Its all at my fingertips. I don't know where Dr. harvard did his research but maybe he just has bad software. My computer system is outstanding and I honestly don't know if I'll ever be able to work in another hospital.

  4. Well by ShooterNeo · · Score: 5, Insightful

    Here's a relevant quote from "Superfreakonomics" :

    The diagnosis was clear: the WHC emergency department had a severe case of "datapenia," or low data counts. (Feied invented this word as well, stealing the suffix from "leucopenia," or low white-blood-cell counts.) Doctors were spending about 60 percent of their time on "information management," and only 15 percent on direct patient care. This was a sickening ratio. "Emergency medicine is a specialty defined not by an organ of the body or by an age group but by time," says Mark Smith. "It's about what you do in the first sixty minutes."

    Smith and Feied discovered more than three hundred data sources in the hospital that didn't talk to one another, including a mainframe system, handwritten notes, scanned images, lab results, streaming video from cardiac angiograms, and an infection-control tracking system that lived on one person's computer on an Excel spreadsheet. "And if she went on vacation, God help you if you're trying to track a TB outbreak," says Feied.

    To give the ER doctors and nurses what they really needed, a computer system had to be built from the ground up. It had to be encyclopedic (one missing piece of key data would defeat the purpose); it had to be muscular (a single MRI, for instance, ate up a massive amount of data capacity); and it had to be flexible (a system that couldn't incorporate any data from any department in any hospital in the past, present, or future was useless).

    It also had to be really, really fast. Not only because slowness kills in an ER but because, as Feied had learned from the scientific literature, a person using a computer experiences "cognitive drift" if more than one second elapses between clicking the mouse and seeing new data on the screen. If ten seconds pass, the person's mind is somewhere else entirely. That's how medical errors are made.

    END QUOTE
    I agree wholeheatedly with the last bit : I can't count how many times I've been to a doctors office or library or other institution and had to wait for a person to pull up my information on "the system". If you're gonna build a friggin computer system to handle local records, for the love of God don't scrimp on the hardware! Optimize the software! It should be INSTANTANEOUSLY fast!

    1. Re:Well by greenguy · · Score: 5, Informative

      I work in a hospital as an interpreter, so I see a lot of how people use computers... and how they don't. Generally in the ER, the patient first sees the triage nurse, who asks a series of questions. The answers all get entered into the computer. Then the patient sees their actual nurse, who asks many of the same questions again. This information may or may not get entered in the computer. Then the PA comes in and asks the same questions a third time. This time, the information gets written on a piece of paper, or maybe a tablet computer. Eventually, the attending physician stops in just long enough to ask the same questions a fourth time, and doesn't enter the info anywhere. If the patient is admitted and sent to another department, the process starts over.

      --
      What if I do the same thing, and I do get different results?
    2. Re:Well by jamesh · · Score: 5, Insightful

      I made a call to HP (abbreviated to protect the company :) recently to have a failed disk replaced under warranty. I went to great lengths to explain that I was a consultant acting on behalf of the customer, gave HP all of my details and all of the customers details etc. I could hear constant typing in the background so something was being entered somewhere. About 20 minutes later I got a call from my office saying they had HP on the line asking who the onsite contact was, who the customer was, and where the part should be sent.

      It's not just hospitals... I think I can generalise the conclusion of the article - if the solution (IT or otherwise) isn't designed/built right, and people don't know how to use it right, then it isn't going to work right and is going to make peoples lives harder not eaiser. Seems kind of obvious when you put it that way though.

  5. The key being ... by devloop · · Score: 5, Interesting

    "IT systems were aimed at improving efficiency for hospital management"

    Doctors and other medical personnel do not typically hold much power
    when it comes to IT.

    Software vendors aim to please management, they are the ones who take
    the purchasing decisions.

    Your typical Lab software for example might not have a straightforward
    way to cross-check isolates for emerging resistance trends,
    run critical screens or automatically report to a global EPI database,
    but it sure has 1,000 ways to generate Aging Reports and auto resubmit insurance claims.

    1. Re:The key being ... by malkavian · · Score: 4, Interesting

      Wow, in the hospital where I work, the doctors frequently turn up to the IT department saying how they've just bought in a new system and they need it supported. If they get told 'no', they complain to the directorate that IT aren't supporting a system based on IT. The directorate lean on IT (with not so veiled threats) until IT support a system they'd have vetoed if they'd be involved in procurement..

      The problem that has been evaluated is that the research was done on an organisation with no true enterprise architecture (at the business silo stage at best). In other words, somewhere that hasn't invested in IT (and likely has the doctors doing what they feel like, with 'homegrown' Access databases and applications, trusting what the vendors say when they produce shiny pamphlets, and either not hiring people who understand how business and tech should map, or not giving them the clout to be able to change the way the organisation works to successfully be able to change things so that they do).

    2. Re:The key being ... by martyros · · Score: 4, Interesting
      Best quote from the article:

      Himmelstein said that 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.

      He pointed to Brigham and Women's Hospital in Boston, Latter Day Saints Hospital in Salt Lake City and Regenstrief Institute in Indianapolis as facilities with some success in deploying efficient e-health systems. That's because they were intuitive and aimed at clinicians, not administrators.

      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.

      In other words, computers are not a magic bullet. They only work well when you actually invest the time to find out what you need them to do, and then make them do that.

      --

      TCP: Why the Internet is full of SYN.

  6. no shit by PhrostyMcByte · · Score: 5, Insightful

    Almost everyone who's ever used a line of business app could have told you this. Good LOB apps will ask the question "how can we use PC to make the experience more efficient?". Bad ones will just say "paper sucks, lets make it digital!" have the exact same fields a paper would have, but make you type it. The bad ones might be marginally easier for management because of their rudimentary search and reporting, but are usually no different or even worse for the actual day to day users.

    Yet management is continually suckered into thinking less paper == more efficient, and there are _a lot_ of bad LOB apps out there because of it.

  7. Of course... by Anonymous Coward · · Score: 4, Insightful

    If you hand a bunch of Luddites a computer system they will tell you it isn't saving them any time.

    The system has to meet the needs of the users.

    The users have to want to use the system.

    If you don't meet both of these requirements it will fail.

  8. Re:I would also guess... by jma05 · · Score: 3, Insightful

    > That some of this has to do with the staff being largely of the 35+ crowd and the propensity of that crowd to not know how to use computers even remotely as well as, say, a 16 year old kid does right now.

    That used to be a favorite argument to explain away poor clinical system adoption. But it does not hold true anymore. An average doctor today is at least as computer savvy as an average teenager. They may not use SMS, twitter or use facebook as much as the teens, but they certainly know how a computer works. This isn't the 90s when computers were optional in life.

    > Computers take more work to use when you don't have a nice grasp on not only the software or function you're doing, but the regular logical deductions you make from repeated observation and experience.

    Good clinical software should not need you to be an expert in computers... just that software... the one they use for several hours each day. And if it takes considerable experience to get up to speed... that's a usability problem... not a user problem.

  9. Designed for Entrepreneurs by wrook · · Score: 4, Insightful

    Computerized health care systems are not designed for the benefit of hospitals. They are designed for the benefit of entrepreneurs.

    Health care is a multi-bazillion dollar industry where information is managed via bearskins and stone knives. Development of an integrated computerized health care system will net the intelligent investor more money than even Microsoft can dream about.

    This is the message that people I will call "serial entrepreneurs" pitch. Their intent is not to build such a system (that would be nigh on impossible given the absolute chaos of incompatible processes that currently exist in hospitals). They simply want to build a system that looks close enough that stupid investors will throw millions of dollars at it. The potential payoff is so big (seemingly) that people will keep throwing money at it even after said entrepreneurs have razed and burned a stack of companies.

    Of course, eventually there *will* be a company that succeeds (mostly by accident). That company will run suspiciously like SAP where there will be a very complex set of computer programs designed to support an even more complex set of processes. These processes in turn will have nothing to do with the underlying business of providing health care. However senior management will be ecstatic that they finally have a unifying computer based process, and the only people who fully realize its true futility will be the people doing the work. They, of course, will be ignored.

  10. Let me explain... by denzacar · · Score: 4, Insightful

    You: Computers have made my life much easier.
    Harvard study: Computers don't save hospitals money.

    Note the slight difference there?

    --
    Mit der Dummheit kämpfen Götter selbst vergebens
    1. Re:Let me explain... by daveb · · Score: 5, Insightful

      >You: Computers have made my life much easier.
      >Harvard study: Computers don't save hospitals money.

      >Note the slight difference there?

      yes - but you missed the bit about efficiency. "Computers have made my life much easier." is usually how we express efficiency.

      Over a decade ago I did a stint at a hospital looking after the pathology database. When it was down and paper records were required then lives were at risk due to the lack of efficiency (time spent accessing paper). It honestly scared me!

        I'm sure things are much much more reliant on computers now. Computers are not just for the hospital admins.

    2. Re:Let me explain... by denzacar · · Score: 3, Funny

      Good? For whom? Patients? Screw them!

      We are talking bottom line here sunny.
      And that bottom line better be in black and with plenty of big numbers.

      Now get out of my way, I have to practice my for the annual Doctor's Golf TournamentTM. It is for some charity or some other bullshit excuse.

      --
      Mit der Dummheit kämpfen Götter selbst vergebens
  11. Parkinson's laws by vurtigalka · · Score: 5, Insightful
    Results like these shouldn't surprise anyone aware of Parkinson's laws. From Why it is Important that Software Projects Fail:

    The boundless creativity of politicians and bureaucrats to develop new and more complex regulation is bounded only by the bureaucracy's inability to implement them. The absolute size of the bureaucracy is constrained by external factors, so the only effect of automation can be to increase bureaucratic complexity.

    Parkinson's laws are as valid and insightful as always. If someone by chance have missed them, here they are:

    Parkinson's First Law:
    Work expands or contracts in order to fill the time available.

    Parkinson's Second Law:
    Expenditures rise to meet income.

    Parkinson's Third Law:
    Expansion means complexity; and complexity decay.

    Parkinson's Fourth Law:
    The number of people in any working group tends to increase regardless of the amount of work to be done.

    Parkinson's Fifth Law:
    If there is a way to delay an important decision the good bureaucracy, public or private, will find it.

    Parkinson's Law of Delay:
    Delay is the deadliest form of denial.

    Parkinson's Law of Triviality:
    The time spent in a meeting on an item is inversely proportional to its value (up to a limit).

    Parkinson's Law of 1,000:
    An enterprise employing more than 1,000 people becomes a self-perpetuating empire, creating so much internal work that it no longer needs any contact with the outside world.

    Parkinson's Coefficient of Inefficiency:
    The size of a committee or other decision-making body grows at which it becomes completely inefficient.

    1. Re:Parkinson's laws by tomhath · · Score: 3, Insightful

      For some large government projects, it gets to the point that it would be cheaper to simply hire 10 different companies to all produce the software product that you wanted, and then simply pick the best one.

      Bingo. You have just pointed out why capitalism beats socialism. Nine private companies fail, one emerges as the industry leader.

  12. Computers need to be implemented correctly... by mgchan · · Score: 3, Interesting

    And they usually aren't.

    I'm a radiologist and computers have definitely improved patient care and saved the hospital money (or alternatively made the hospital more money) in our field. From digitized images and the ability to outsource to overnight coverage to voice recognition to get turnaround for finalized reports in an hour it has undoubtedly worked. And that's with in most cases only fair implementation of a computer system.

    With most hospitals, the problem is that they like to do a piecemeal transition. Digitize a subset of notes and vital signs, half the time what you need isn't there so you have to look through the paper chart AND the computer chart. Or the vital signs are only half in the computer and half on a chart, so nurses double their workload. And when it's set up, they do it with an IT-centric interface that doesn't make intuitive sense to most users. When I use them I can see through my background in computer science and engineering why things are done a certain way, but it doesn't make any sense to physicians, nurses, etc.

    Then they add in a new piece, such as more vital signs (but in a different section), some dictated notes, some linking to the outside. Outpatient notes are digitized, inpatient notes are still handwritten, etc. ED notes are separate, with their own system. It's a complete mess. This method is a waste of money and time, all for the sake of early deployment of a suboptimal system and minimal re-training of the staff to use a new system.

    The VA had a decent attempt with CPRS. They digitized everything - from physician admission notes to clergy notes. At least everything is in one place, but people are overwhelmed with data and it's too easy to copy and paste incorrect or inaccurate information. The interface is also suboptimal (graphing lab values involves selecting a range of tests, building a worksheet, etc. much like you'd expect an engineer to make it for maximum flexibility, but minimal ease of use). And connecting to other VA systems is hit or miss.

    Perhaps the best method is to build a new hospital from the ground up. All patient records get digitized (scanned, at least, if not run through some OCR). Have a tightly integrated medical record system developed in collaboration with health care practitioners. That would save the hospital money, in the long run, compared to them starting from scratch with paper records.

  13. building bad clinical systems is harder by r00t · · Score: 5, Interesting

    We are over ambitious. The more code we write, the more bugs we create.

    The trouble with hospital data is that it is messy. You have to accept that.

    It's tempting to design a hospital data system with specific fields for each item, every procedure enumerated, and every field validated. You want to normalize your data. You want it neat and tidy. You can work very hard trying to enforce this. You're screwed though, because life isn't like that.

    You'd be better off with relatively "dumb" software, almost like a wiki, that lets you efficiently handle arbitrary text and arbitrary data blobs. It needs fast Google-style search. It needs to allow arbitrary associations so you can handle stuff like a patient claiming to have the same social security number as a different patient or a patient who claims to have a different identity than he did the last time he visited.

    Then you need to keep medical staff away from both paper and computers. Data entry is for data entry specialists.

  14. My experience in medical information mgt ... by LaughingCoder · · Score: 3, Insightful

    I developed products in this space for a number of years. One big problem we always encountered was the in-house proprietary systems. Time and again we would hear "we'll buy your system as long as it can interface with this shiny, homegrown monstrosity that we developed". Of course the person most responsible for the purchasing decision (at least from the technical end) was also usually the manager who was responsible for creating (or at least maintaining) the inhouse monstrosity. To throw it out is to admit a giant mistake, to potentially cut staff (and hence reduce power) and so instead they try to make vendors jump through hoops. Our natural response was to wrap our products with integration services, which breeds a support nightmare (no two customers have the same thing) and is also very labor intensive, and hence expensive, making it very hard to justify for the projected "savings". As an example, I once spent a year (mostly on my own time each night at home) logging in remotely to a hospital system, running migration scripts to move image data from an inhouse system into our system. Each morning I would tell the customer's technician to load a new batch of disks, then I would kick off the migration each night. And mind you, this is ONE customer at ONE hospital. And of course first I had to write the migration scripts ... another sunk cost.

    --
    The more you regulate a company, the worse its products become.