Why some EMR programmers think physicians are stupid

Every major industry is now computerized with one glaring exception; health care delivery. Thirty years after Steve Jobs began selling personal computers out of his garage, far less than 50% of physician practices and hospitals have converted to any form of electronic medical record.

The vast majority of medical documentation is still done via paper and writing utensil just as it was 100 years ago.  For a society and economy that has fully transitioned from being mostly industrial and manufacturing based to being primarily information based, this is a stunning omission.

The reasons for this are varied and complex but in an article that spotlights several lows in the career of a software programmer, Scott  Reynolds writes about one experience with coding software for the next generation of electronic health records and what happened after it was finished, shipped to the customer, and went live:

You didn’t know what to do with yourself so you sat there all day refreshing a view on the database to spy on what [the first few customers were] doing. Answer: not much. The things they did do, they did wrong. They found bugs. They found ways to circumvent all of your carefully constructed system rules and validations. Not because they were master hackers or brilliant technicians … but because they were just stupid.

They clicked on things they shouldn’t click on. They typed things in that they shouldn’t type in. They didn’t read simple instructions. They didn’t listen in training. They were personally insulting you by being terrible at using your software.

In a field labeled “Enter the number of specimens:” they typed “five specimens.”

In a field labeled “Social Security Number:” they typed “he doesn’t have one because he is an illegal.”

Instead of using the button labeled “Create New Patient Record:” they kept changing the information in a single patient record over and over and saving it.

Then the calls came in from the sales team demanding to know why the system was broken and why you had taken so long to develop something that clearly didn’t work.

There was nothing you could do but respond to the bug reports and issue system patches that added no value other than handholding people through the software. You wondered aloud how these people had managed to survive this long without drinking bleach by accident.

Sad but very true. Like many industries, the medical business is loaded with tons of paper pushers, unmotivated mid-level managers, mindless bureaucrats, poorly trained ancillary staff, and lucky professionals who slipped through the cracks and managed to get a degree despite being borderline bleach drinkers.  It’s far easier to conceal stupidity, laziness, and incompetence while utilizing a paper based documentation system than an electronic one.  Paper documents are regularly loaded with errors, inaccuracies, and out-right crap. Lucky, very little of this has any impact on patient care or is discovered until the chart is audited by insurance companies, Federal agencies, or malpractice attorneys.

It’s not until the paper form is replaced by a computer that can fact check and give instant feedback that the massive scope of all this crap documentation becomes known. It’s not just that people are “computer illiterate.” At the hospital where I work, forms are regularly incorrectly filed under the wrong tab in the paper chart, medications are misspelled, illegible test results printed long after the printer toner has run out, daily weights randomly documented using lbs or Kgs, blood sugar levels written in the blood pressure column, etc. etc.

Combine this fact that the health care industry is not immune to employing bleach drinkers with the fact that it’s inherently a very complex information system and we start to get an idea of just how daunting a task it is to design a software system for health care documentation.

But, then again. As the article makes obvious, why is a software programmer designing and coding  a computer system for health care? Isn’t that like an oil company executive designing a formula one racing car or lawyers writing health care legislation? Yea. That.

Chris Rangel is an internal medicine physician who blogs at RangelMD.com.

Submit a guest post and be heard on social media’s leading physician voice.

Comments are moderated before they are published. Please read the comment policy.

  • http://thoughtbroadcast.com SteveBMD

    I agree with your assessment of the lazy, incompetent, error-prone (read: “human”) people who work in health care. Hey, I’m one of them, too.

    But you do realize, don’t you, that Scott Williams is a satirist and this was written for a humor column?

  • Tom Young

    Programmers and IT people are not physicians, and Physicians are not generally IT people or programmers. Clearly the use of computers in healthcare has been common place. I’ve been in medicine for years (22) and have electronic records going back that far. In the early years, I also had hard copy. The programmers, outside of the VA system, had not written any commercial recognized EMR packages. I used MS word and had the ability to search text. The programmers were behind the curve. Now I use Amazing Charts. Most physician practice models do not include budgets for large tech related purchases. Try and buy anything for the “medical” profession and then explain to me why the cost is in multiples of similiar products in other fields of endeavor. Cost is clearly an issue when purchasing an EMR. Programmers do not know how physicians think or how they practice medicine. There is a western medical model that has been hammered into us from the first day of med school. Now, years later, a programmer writes some code which in effect tells the doctor how he should practice medical and rearrange his thinking. The problem is not in trying something new. It has more to do with putting together some poorly written code and expecting Physicians to pay homeage to it. Amazing charts was written by a physician, for physicians. There is no reluctance among the AC users to try and create work arounds, or make suggestions to improve the product. As far as the “pencil pushers” who continue to keep records with pen and paper, maybe they are smart enough to know that we are a long way from having a user friendly program out there that compliments the way a physician practices, not dictates it.

  • http://hightechsurgeon.blogspot.com JF Sucher, MD FACS

    I’m not sure if I really understand this post. Maybe because I’m stupid?

    Here is my take… one with the perspective of having programmed medical software and being a practicing surgeon: Scott Reynolds “Humor” article is a prime example of how poor the software is for the medical industry. Let’s take his examples of user “stupidity”:

    1. “They found bugs.” – Sounds like bad programming to me.

    2. “They found ways to circumvent all of your carefully constructed system rules and validations.” – Again… sounds like bad programming to me… must not be so carefully constructed.

    3. “They clicked on things they shouldn’t click on.” – A good program wouldn’t let you do that.. Again bad programming.

    4. “They typed things in that they shouldn’t type in.” – Lets see… BAD PROGRAMMING anyone??? Any good program validates fields so this doesn’t happen.

    5. “They didn’t read simple instructions.” – Who needs instructions if the program is so well constructed and written?

    6. “They didn’t listen in training.” – Ok… you got me on that one.

    7. “They were personally insulting you by being terrible at using your software.” – That’s right… blame the user… It would be kind of like me blaming the patient for dying after all of my careful work in the operating room!

    8. “In a field labeled “Enter the number of specimens:” they typed “five specimens.”” – Well… what happened to your carefully constructed “rules and validations”??? Again BAD PROGRAMMING

    9. In a field labeled “Social Security Number:” they typed “he doesn’t have one because he is an illegal.” – AGAIN.. BAD PROGRAMMING..

    10. “Instead of using the button labeled “Create New Patient Record:” they kept changing the information in a single patient record over and over and saving it.” – Sounds like the programmer completely failed AGAIN.

    OK… I’ve grown bored at pointing out how terrible this “programmer” is at his job. Thank you for making it so easy for me to point out why the EMR industry is filled with horrible software.

    And as for RangelMD… Why are you directly insulting the health care workforce? For what end? Calling them “bleach drinkers”. Really? Is that supposed to be humor? Shame.

    And finally your last paragraph:
    “But, then again. As the article makes obvious, why is a software programmer designing and coding a computer system for health care?” — Who should be designing and coding a computer system? The last time I checked… It has always been a computer programmer / software engineer. It always will be. Unless you can come up with some other title for an individual who writes software code that allows you to perform tasks on your computer.

    The fact is.. There is a ton of input from physicians and nurses and technicians. But the fact is, there is no money in it to design a “killer” clinical system. The industry is going after making sure that you meet this metric or that indicator. The systems are looking to get boxes checked so that administrators and regulatory agencies can manipulate the finances of who gets paid for what. As long as they can tell you (the nurse, physician, tech, whoever) to do more with less… that is what will happen. The fact is, it is much easier to ask you to make up for the inadequacies of the system, than to pay for the enormous cost of creating a system that actually helps you do your job more efficiently.

    • http://www.consentcare.net Martin Young

      Hear, hear!

      Bad programmig, all of it. Another examples of non-medical people with zero insight deciding what is best for the medical profession.

  • Michelle

    No software is going to stop someone who is not paying attention from putting someone else’s medication, condition, procedure, etc., on my record (this has happened to me), or something of mine on someone else. Human diligence is vastly more important than whether record are paper or electronic.

    • Jason

      This is correct, Michelle, but well designed software would make it trivially easy to correct the human error in the scenario you describe.

  • http://www.picumd.com PICU MD

    I think the reality is that EMRs as they exist today are the equivalent of using Windows 2000 vs. doing something on your iPad. Unfortunately the systems are so focused on JCAHO mandates, PQRI, meaningful use (which in and of themselves aren’t bad things), and having structured data that MDs who are relatively unstructured have trouble adapting.

    Consider that I can give my 2 year old who can’t read an iPad and he has figured out (with zero input from me) the basics of how to move from screen to screen and find and use “his apps” in a matter of about 20 minutes. Or that I can do online banking and bill paying with out an “in-service”. That’s the level of simplicity we need to strive for with our EHRs.

  • http://guelich.net Scott Guelich

    At the risk of this being a pile on, I agree with the previous commenters. This post seems misguided at best.

    I also also have many years of software development experience, and the EHR example outlined in the quote demonstrates a lazy programmer doing improper data validation and then blaming users. So why the attack on fellow health care workers? Health care workers should be able to focus on health care, without worrying about how databases work (does this field require an INT?).

    We need to stop asking clinicians to adapt to technology and instead design technology that’s adapted to them.

  • http://www.carecloud.com/ Michael Gold

    Much of the text in the post reinforces something that Alan Cooper once wrote: “Programmers think in ways that are sympathetic to silicon, and they imagine that everyone thinks in the same way.”

    Clearly the users mentioned by the programmer quoted in the blog post did not think like a programmer. In this respect Dr. Sucher’s response is spot-on.

    Clinical users should not have to think like programmers. In fact we should be designing systems such that clinicians can use them while relying on their clinical background alone, without months of vendor training, and with no impact to cognitive load.

    As designers, we need to observe and intimately understand our users, their roles, their backgrounds and their many goals. It is only through this understanding combined with proven interaction patterns that we can create systems that are easy and compelling to use, and that do not require workarounds.

    Up to now, we in the Healthcare IT industry have done a notoriously poor job creating compelling user experiences for clinicians. Shame on us.

    We are not going to let that continue anymore.

    • http://thoughtbroadcast.com SteveBMD

      Case in point: our e-prescribing system classifies meds according to NDC code, not by name. So when I go to prescribe “fluoxetine caps 20 mg qd #30″ (which is that easy on paper), I get at least two dozen different options for fluoxetine and have to find the right one. And if I pick the wrong one, it means 30 minutes of faxes/phone calls to/from the pharmacy, and a delay in the patient getting the med.

      Now that’s compelling. Compels me to throw the freaking thing out the window.

      • Primary Care Internist

        exactly the same with our system.

        and if someone is on, for example 6.5 mg of coumadin, one needs to enter two separate coumadin orders (4mg daily adn 2.5mg daily), then go through multiple meaningless conflict screens, some of which indicate “this drug may interact with unspecified additives in [fill in the blank]“.

        total garbage, and if anything not just neutral, but easily has the potential to CREATE medication error.

  • http://hightechsurgeon.blogspot.com J.F. Sucher, MD FACS


    I have studied this field extensively. I have reviewed its history and tracked it since 1959.

    1. The “technology” may “technically” be here. But its not implemented, nor deployed in any reasonable fashion to satisfy the needs of physicians. This is clear. Its not that it can’t work. It just doesn’t work for the masses.. YET.

    2. The health care industry has no problem with change. It changes constantly. This is not the issue. The issue is that the software is exceedingly poor. This can be improved.

    3. The generation of computers that you speak of fails to appear. I am 45 years old. I know more about computers than 95 percent of the 25 year old medical students that I meet every day.

    4. You naively talk of physicians giving their “suggestions”. There is no lack of suggestions. Just a lack of someone capturing what the clinician needs and can use. There are many reasons for this. I could give them all, but it would be a dissertation.

  • soloFP

    My local hospitals have been using some form of electronic records and databases for about 20 years with multiple updates. I have patients that are listed three and four times, secondary to the wrong DOB, transposed first and last names, and simple human errors. The labs and stuides end up in three different files without the ability to merge records. I have experimented with the optional but soon mandatory physician medication order entry. If I type in HCTZ, I get about 20 choices. To order a CMP or a CXR, I have to go through multiple screens. Don’t type in CT, or you will get about 100 choices. The current med entry system is to print out all the patient’s home meds and have me sign them. It is faster to write the meds in the chart on one 1 page of paper paper than it is to sign 4-5 pages of admission meds. On the flip side, I would love a system that lets me do my hospital notes in templates, as many days I simply repeat the same information in SOAP note style with 1-2 sentences that change and feel like a scribe to meet the various Medicare coding requirements. A good EMR would save me a lot of time in the hospital. Especially if the EMR would work with my iPad.

  • MarylandMD

    This reminds me of a talk I went to a long time ago before I went to medical school. A PhD psychologist in the drug addiction field was giving a talk about his research study that involved computer input by patients in drug treatment. The patients got a small reward for wrong answers to questions, and a bigger reward for right answers. He noted that an individual started giving repetitive “wrong” answers to questions, and the practice spread to other patients in the study, in the end causing them to shut the study down due to bad data. The PhD kept talking about how “stupid” the patients were to repeatedly hit the wrong answers. His contempt was quite clear. After I asked him a few questions, it became apparent that the patients in the trial had discovered they could make more money more quickly by rapidly answering all questions with the same answer (right or wrong) than by taking the time and trouble to figure out the right answer for each question. In the end, the only one who looked stupid was the PhD researcher who had been outsmarted by his research subjects.

    It is really pretty rare that you find someone who is truly stupid.

    People do wrong things with computers because they are poorly trained. Or the interface confuses them. Or the layout is counter-intuitive. Or they know they aren’t doing things quite right but they are really busy and they get the job done quicker if they do one part of it the “wrong way”. Or something else you just haven’t thought of. Taking a little time and effort to work with the end-user to find out why they do what they do would go a long way to helping programmers design better software. Just a thought.

    But whatever you do, don’t call them stupid.

  • http://onhealthtech.blogspot.com/ Margalit Gur-Arie

    Let me just point out for PICU MD that the iPad software was written by programmers. So why is it so much better?
    Your banking software, which for some unclear reason keeps coming up in this context, was also written by programmers. Any good software that you care to mention was written by software engineers and programmers.
    Bankers do not write software. Consumers do not write iPad software or banking software. Pilots do not build airplanes. Soldiers do not build tanks. I could go on, but you get the idea….

    So why is it that EHRs are so inadequate? I think that’s the wrong question. Let’s try again:
    Why on earth are you buying a product that obviously is not what you want?
    Consumers have driven quality up and price down in every field. Physicians are consumers and obviously know better than buying clunky cars, phones, tablets, and whatever else you are buying.
    Where is the breakdown when it comes to an EHR?

    • Djapink

      The breakdown is that people (physicians/management/other stakeholders) assigned to choose an EHR are not able to understand and properly assess functionalities in products by just seeing a short demo which is most of the time purely cosmetic and shows only the upsides of a product. The missing functionalities are mostly not clear because of lack of workflow-assessment before starting a trajectory.

      Therefore you might need a specialized organisation which is able to guide a hospital/care-provider and show comparative data on all available EHR’s. Then an assessment has to be done internally checking and thoroughly describing the vision and workflow in the institution. After that a institute should adapt its way of working by training, internal communication and getting it accepted before (!) choosing a product and implementing that EHR-solution. Otherwise all the workflow-optimization issues will we be addressed to the new EHR-solution and not to the already necessary workflow optimization and standardization in an institution. Without that standardization an institution-wide and multidisciplinary approach by a software-vendor is almost impossible to program and to maintain.

      • Tom

        You’re almost right, in that in most cases, the purchasers have a very different goal in mind. Usually the purchaser has in mind the goal of improving billing and revenue. Some systems, notably Epic, can be made to do that. Having said that, there is frequently a disconnect between what the billing department and the clinicians want in a product. At present, software is being written for the billing department.

    • http://www.consentcare.net Martin Young

      Lack of consultation beforehand. Noone builds an aeroplane that the client does not need.

      So why do EHR vendors build software without a needs analysis from doctors?

      I built my own system using freely available programs because the other options were so bad.

    • http://www.carecloud.com/ Michael Gold

      Clearly, programmers/engineers did develop iPad, banking apps, etc.

      What iPad and some (but certainly not all) online banking apps have in common, and what most EHR products out there lack, is design based on the understanding of user needs, goals and emotions; combined with the discipline to avoid letting the design be guided by the strictures of pre-existing architecture or implementation, the siren-like convenience of code/component reuse, or the self-referential nature typical of programmers/engineers. It takes strong will, and there is no better example of this than Jobs/Apple.

      When a usable and delightful EHR emerges that clinicians actually love to use (crazy and naive as that sounds), consumers will vote with their feet.

    • pcp

      I think programmers have been given an impossible task.

      We’ve instructed them that EMRs must:

      1. lower costs
      2. eliminate medication errors
      3. provide best practice info at every step
      4. collect and store data from multiple silos
      5. lower staffing needs
      6. increase charges
      7. basically, fix everything that’s wrong with American health care,

      all built on the truly unmanageable CPT system.

      Until the stakeholders decide exactly what we want EMRs to do, the programmers are going to struggle.

      • http://thoughtbroadcast.com SteveBMD

        “7. basically, fix everything that’s wrong with American health care,”

        Don’t know if you’re trying to be facetious here, but if that was meant with any sincerity, that is precisely the problem.

        As a clinician, I welcome computers to my practice because they make me more efficient and effective. But when I say “computers” I mean nothing more than a PC with a word processor, web browser, and printer. That’s it.

        So far, every system I’ve worked with (with the exception of the VA) gets in the way of the clinical interaction. And that is what’s wrong with American health care.

    • http://thoughtbroadcast.com SteveBMD

      “Why on earth are you buying a product that obviously is not what you want?”

      I didn’t buy the product. In fact, no one asked me for my input.

      Seriously, the physician may be the “end user,” but the purchasing decision is often out of the physician’s hands, and made by someone whose priorities are very different from the physician’s.

    • http://www.picumd.com PICU MD

      As far as the banking software, it’s an easy example and honestly it’s nothing special. I find most of the online websites for the banks I use fairly intuitive. If you want another example try Peapoding your groceries.

      My role in IT is at the hospital level so most of the end users (nurses, MDs, etc) cannot make the choice about what software to use. I guess I feel like the primary aim’s of the software coming out these days is to meet meaningful use or collect required data for quality measures. However, there is not heavy focus on end user speed, efficiency and ease of use. Also, more emphasis needs to be placed on real, meaningful decision support (not just alert popups).

  • AppDev

    As a software developer working on electronic health records, I was appalled by Dr. Rangel’s descriptions of electronic health records (EHR) “mistakes” by supposedly “stupid” physicians. It is the job of software developers to understand the language and thinking patterns of those who use their products–not the other way around.

    The details of those supposed mistakes show, again and again, first-grade errors by software developers, not by physicians: failing to validate data entries immediately, failing to set up unambiguous usage protocols, failing to provide effective training, and failing to interact with users the products and adapt to their needs, skills and language patterns.

    There are plenty of genuine problems installing and supporting EHR systems, but all those that Dr. Rangel mentions are avoidable and would not have happened with a competently designed system.

  • Jason

    I’ve been writing software for 25 years (getting paid for 15 of those) and in the medical industry for 5. The fact is, we think all users are stupid, there is nothing special about the stupidity that comes from the medical industry. Users are going to break things, they’re going to do things we didn’t expect, and they’re going expect things out of the software that we would have considered unreasonable.

    The paradigm of the “Stupid User” has been around since the beginning of software, and so I am stunned at the examples of how users supposedly misused this software. There is nothing listed that couldn’t be prevented by correctly designed software.

    Here’s a subtle example of bad software that every one of us deals with (at least in Windows) to this day, that could so easily be fixed: If I have a Word document open with unsaved changes (or even never been saved), and I click “Start > Shut Down”, Windows actually asks me if I want to save the document. Really? I have a terabyte disk drive with 97% free space, and you don’t think you could just, I don’t know, save a copy for me and ask me later if I go looking for it, or if I start Word again?

    A computer can beat Ken Jennings at Jeopardy, but mine isn’t smart enough to save a copy of something without asking me first? When I go home for the day, my desk doesn’t ask me, “Hey you! Do you want me to throw all this paper in the trash!?”

    Sorry. My reasoned calm comment turned into a rant. As a software professional, bad software makes me cranky!

    • gzuckier

      or at least have an option you could check for always save. or even choose always save, always delete, or ask.

      but just about every piece of software i use has something in it that annoys me, whether as part of its design, or else a bug. adapting to users isn’t the biggest thing programmers get rewarded for, generally. early automobiles weren’t particularly easy to use either, but they’ve continually gotten better.

  • Ralph Leask

    Simple facts – in general – Doctors are not information systems experts AND information systems people or not medical experts.

    But then a similar statement can be made for almost every area for which software had been developed to help in the automation of the processes. In most fields, if a programmer decides to write a software package and sits down to do so without interfacing with the people who know the field being worked on, does no research and asks for no feedback the result is predictably a failure – unless the subject being tackled is commonplace or trivial or both.

    Successful software development has always come from being able to bridge the gap between the subject matter and the systems. In the past this used to be done with teams of systems people ranging from business analysts and systems analysts through programmer/analysts to plain programmers. One of the objects being to keep the users and the programmers as far apart as possible, to stop them both from killing one another for being “Stupid” and not understanding everything.

    As the use of information technology has proliferated, both in the workplace and in personal use, there has been a tendency on all sides to think that developing systems is easier than it really is. Bring that into medical practice which is neither commonplace nor trivial and the stupid people on all sides have ample room to develop catastrophic solutions.

    I have been involved in working on developing software for physician use, and the real progress and success began to happen when everyone involved realized that a team, in which physicians were willing to adapt and accept it was possible for technology to help them, and programmers were willing to realize that their system was pointless unless it could do something for the user, could produce worthwhile results.

    Of course there are exceptions and it is possible to find a programmer with the insight to do his own development for a user in an area that the programmer is not a trained expert. And there are users perfectly capable of learning programming and devleoping there own systems. But these are not the general rule and you cannot count on finding them as the way to plan ahead for success.

    By the way, I enjoyed the article in the spirit in which it was written. The above comments are more for the previous commentators than anyone else.

  • Kevin N.

    The technology is there, but health care systems don’t purchase the technology that physicians actually want. I’m in the military, so I have to use AHLTA, which is probably the worst software ever developed (it has the look/feel/functionality of a community college’s Intro to Visual Basic course final project).

    However, I’ve learned to create my own EMR systems. When in the desert, with (thankfully) no AHLTA, I built MS Access patient database that printed documents via Mail Merge with MS Word. Worked perfectly because I designed it precisely for my needs. Back stateside, my current operational assignment requires me to track a large patient population (i.e. over-educated case manager), and I use FileMaker on my Mac, which again works perfectly. I use DevonThink to store all my PDF papers, texts, etc., which I can search blazingly fast to get whatever info I need. I use the software Things for my GTD / ‘to-do’ tracker.

    Again, the software is there, I just don’t ever expect any healthcare bureaucracy to provide it.

  • horseshrink

    Lively discussion that puts a smile on my face! I feel thoroughly vindicated, by colleagues and code writers alike.

    I work in a large, state-wide system in which non-clinicians (bureaucrats) purchased an abysmal EHR product. I’ve yet to find a colleague who prefers this system over paper.

    However, my employer is married now to the vendor-specific idiosyncrasies of a very large database. As I’ve looked at what keeps us paralyzed from changing to a different EHR, I’ve learned something basic.

    New product cost + data migration cost = prohibitive cost.

    What if data migration cost was removed? What if all medical data were as standardized as World Wide Web data? What if, as a result, docs could change EHR products at will, with the same ease as changing internet browsers?

    Vendors could no longer lock clients into products, so market competition would heat up. Vendors that wanted to remain in business would become much more interested in what the end-user EHR customer actually wants, and code accordingly.

    In this way, Adam Smith’s “invisible hand” can solve much of what plagues our present EHR experiences. It was this invisible hand that buried Apple’s Newton, but later breathed life into the iPad. No federal intervention required.

    • http://onhealthtech.blogspot.com/ Margalit Gur-Arie

      The same “invisible hand” arranged things so that applications running on any Apple platform will not run on Windows or Android and vice versa, and the browser that works on Apple devices doesn’t work on a Dell, etc.

      I do understand your wish and it is a good one, but EMRs are way more than an almost passive window into medical data, which is what browsers mostly are. EMRs are transactional applications and massive ones at that. They display, collect and alter data in intricate ways. Database content and design is at the heart of a transactional application.
      Ask your local bank branch manager, how easy it would be for him to change his enterprise software, and you will find that he is as stuck as you are.
      You may use any browser you want to access your bank account, just like your patients can use any browser to reach their Portal, but in both cases, the enterprise software behind those browser views is proprietary and pretty unmovable

      All that said, I don’t think federal intervention in its current form is very conducive to quality improvements in EMR usability.

  • horseshrink

    You’re right … I’m oversimplifying somewhat with the browser analogy. I hope, though, this effectively highlights a current problem of vendors locking clients into products through proprietary data structures. When data is standardized, vendors behave differently.

    For the sake of HIE, and for the sake of broadening clinician adoption, I think the data layer should be standardized. Vendors can then compete for end-user dollars as they shop for data input, mining, analysis and viewing applications.

  • AnnR

    I’m a programmer and I think referring to your users as “stupid” is an idiot thing to do no matter what industry you are trying to automate.

    Even if they aren’t directly paying your salary if you disregard them you will soon be an unemployed programmer.

    Obviously these “stupid” medical personnel out-smarted the programmer in figuring out how to enter bad data. I for one always welcome users who want to test out my software because they come up with actions more real than anything I could have anticipated.

    To me the moral of this story is that if you are going to go with an EHR you must have the people who will use it devote time to working on the design and test of the system — even if they are much too busy/important. Otherwise you might as well just flush and be done.

  • rezmed09

    Somehow docs can use Email, order on-line, buy plane tickets on-line, do their taxes with a computer or do CME on-line or with a program. Somehow docs can install software and debug a computer. Somehow they can play all sorts of complex games on computers.

    But when a doc finds an EMR program clunky or time wasting, he/she is stupid. I think the problem is not between the Doc and the software, I think the problem is between the programmers and what the docs need to help them take care of the patients. The programmer don’t work for docs, the docs work for the programmers.

Most Popular