Why Doctors Should Stay Out of the Business of Building EHRs

The original Hipoocratic Oath states:

I will not use the knife, not even on sufferers from stone, but will withdraw in favor of such men as are engaged in this work.

One modern version reads:

I will not be ashamed to say “I know not,” nor will I fail to call in my colleagues when the skills of another are needed for a patient’s recovery.

The idea here is that a doctor needs to recognize when another practitioner has a skill that they do not, and that they must refrain from “practice” when another person has demonstrable expertise in that area of practice.

It is now 2013. It is time for doctors to stop “writing their own EHR” from scratch. They need to bow out of this in favor of people who have developed expertise in the area.

I just found out about another doctor who has decided to write his own EHR, because he has not been able to find one that supports his new direct pay business model adequately. In the distant past I encountered a doctor who believed that his “Microsoft Word Templates” qualified as an EHR system. This is a letter to any doctor who feels like they are comfortable starting from-scratch software development for an EHR in 2013 or later.

You might believe yourself to be an EHR expert.

Are you sure about that? Are you sure that you are not just an EHR expert user?

This difference is not unlike your relationship with your favorite thoracic surgeon. Or for that matter, your relationship with the person who built your car. The fact that you are capable of expertly evaluating and using EHR products does not mean you are qualified to build one. Just like the fact that you are qualified to treat a patient who has recently had heart surgery or to discern when a patient might need heart surgery does not make you qualified to perform that heart surgery. Similarly, the fact that you can drive, or even repair your automobile, does not provide you with the expertise you need to build a car from scratch.

The ethical situation that you are putting yourself in by developing your own EHR is fairly tenuous. Performing heart surgery without being a heart surgeon, building and driving your own car without being an automotive engineer and a doctor coding their own EHR system from scratch all have the same fundamental problem: You might be smart enough to pull it off, but if you don’t you can really mess up another person’s life. Make no mistake, you can kill someone with a shoddy EHR just as easily as by performing medical procedures that you are not qualified for or by driving a car that is not road-safe.

It is not that heart surgeons, automotive engineers and EHR developers are not going to kill people with faulty performance. All experts are fallible. But they will kill far fewer people than you would, performing outside your expertise.

I can understand your feelings of frustration. You likely have totally different goals in mind than the average third-party-payer oriented EHR system has. You are right to be frustrated with the shackles that those systems have placed on you. But you are very wrong to presume that it is ethical for you to do “amateur hour” on your own.

You presume that because you can see the problems with EHR developer performance, that this makes you qualified to build a better EHR. You are utterly and unequivocally wrong about this. Sometimes, EHRs have features that are designed for clinical CYA, basically over-documentation for the sake of unethical defensive medicine. Sometimes EHR systems are designed to be glorified practice management systems, designed mostly to ensure that doctors maximize their paycheck at the expense of patient care. Sometimes EHR design decisions have no rational behind them at all… they are frequently the result of original design whims that are hard to correct in subsequent editions of an EHR product.

But sometimes a feature that frustrates you is precisely what makes that EHR safe for patients. I can promise you that you cannot tell the difference between flaws and features without looking carefully at both the internals of the EHR system and all of the clinical workflows it is exercised in. What you think of as a flaw might be a software crumple zone.

Happily, you get to have your cake and eat it too. There are several Open Source EHR systems that are already meaningful use certified. You can use these Open Source EHR systems for nothing, and for very little money you can even get Meaningful Use credit for using these systems. Given this, you have no excuse to continue to develop an new EHR.

Open Source gives you the right to change what you need to, in order to get the functionality that you want.. and more importantly can connect you with experienced health IT developers, who can serve as a gut check for you as you consider how to implement the features that you need for whatever clinical variation you are interested in implementing.

This is very like the person who orders a “kit car” to build in their garage. They get to -feel- like they are building the car, and indeed they get lots of options normal car owners do not. But in the end, they are able to build a car safely because someone else, someone with specific expertise, has made sure that design of the kit car is fundamentally sound.  You can always shoot yourself in the foot with kit cars and Open Source.. but you have the power you need without being in over your head.

The development of mature EHR systems has been very similar to the development of surgical methods. Primitive EHR systems and primitive surgical procedures were both deadly. In both cases, medical science has already sacrificed thousands of people to the “cause” of learning how to do these things right. In 1850, it would have been entirely appropriate for any doctor to “dabble” with creating their own surgical methods. Even as recently as 2000, it would have been appropriate for you to “dabble” with the creation of your own EHR system. (eMDs was started by a doctor dabbling in 1996. eClinicalWorks was started in a similar fashion in 1999). But those days are over.

A doctor developing a new EHR system from scratch, by themselves, without extensive Health IT programming experience is in over their head. If they continue to develop an EHR, even after being warned of the dangers here, then this is hubris.

Ask yourself: Are you absolutely sure that this action is not a fundamental violation of the oath that you took when you became a doctor?

I want to be clear, I have worked on or around the development of EHR systems for more than a decade, and I would not presume to write a new EHR system without a team of programmers and years of funding. Its not that I think that “a doctor” is not qualified to undertake this task. No single person is.

I wrote a book designed to ensure that novice programmers had basic training in complex Health IT principles. Programmers can be guilty of hubris too, and I consistently advocate for a “clinical pair programming” approach. David Uhlman (my co-author) and I wrote the book because too many people assume that Health IT is easy, and they wonder why things in the industry are so “primitive”. The book is intended to teach clinicians and programmers alike humility when approaching clinical information systems, both as users and as developers. FSM knows that I have been dangerously arrogant regarding clinical information systems, and I have and will make serious mistakes. But there comes a point where making the same mistakes that others have made, and written about, becomes unethical. I think we have reached this point with EHR systems.

Some people took offense that I should link to my own book at the end of this article, so instead I have included some of the reference materials that I use frequently. This is a good sampling of the kind of context that really should be required of any modern Health IT developer.

Begin with Information and Medicine by Marsden S Blois. Then move on to Principles of Health Interoperability HL7 and SNOMED by Tim Benson and The CDA Book by Keith Boone. Finally, you should read about what can go wrong in Health IT by studying EHR generated errors with Clinical Information Systems, Overcoming Adverse Consequences by Dean E Sittig and Joan S. Ash.

These are the books that I refer to when I get stuck on something. I wish I could just hold it all in my head, and in many ways my book is just the cliff notes I need for myself. If you know of other books that should be on the “Health IT required reading list” please leave them in the comments…

Fred Trotter is a healthcare data journalist and author. He is a technical blogger for O’Reilly Radar and is the co-author of the first Health IT O’Reilly book Hacking Healthcare. Fred Trotter is deeply involved in the e-patient movement, the quantified selfmovement, the health 2.0 community. In all of those environments, Trotter has focused on building tools that help empower patients to improve their own health. You can follow him at his personal website, where this post first appeared.

Spread the love

30 replies »

  1. While I have already exhausted this issue as I have way more evidence that suggests that PATIENT CARE HAS TAKEN AN EXTREME SLOPE IN A DOWNWARD SPIRAL OF “DOOM” AS THEY HAVE BECOME INCREASINGLY NEGLECTED DUE TO THE IGNORANCE OF : no consistent E.H.R that has long-term value, (unless they are a monopolizing entity-healthcare system) — that is unable to communicate in the health exchange of information, that requires unrealistic expectations of health practitioner’s to be proficient, no consideration for the generations of patients that refuse to buy into the E.HR., the stress of financial burden and /or penalties threatening doctors to meet deadlines taking priority over their mental, physical and emotional intelligence that makes them devoted to the oath they live by…
    So while health practitioners are trying to reach attestations, learn ICD 10, maintain accreditations, be responsible for training all aspects of the E.H.R. to a wide variety of users, I FIND IT INTERESTING THAT DURING THE RECENT CONGRESSIONAL / SENATE HEARINGS ABOUT I.C.D. 10, there were only “TWO”, I REPEAT: “TWO” PHYSICIANS who worked directly with patients, THAT WERE GIVEN A VOICE about adding ICD 10 to the workload.
    BECAUSE THE WHOLE PROCESS (although if introduced properly and slowly) HAS FORGOTTEN ONE IMPORTANT ELEMENT.
    What is evident is a huge decline in safety of patients, health care practitioners and the ability to keep patient information private.






  2. What’s Taking place i am new to this, I stumbled upon this I have found It absolutely helpful and it has aided me out loads.
    I hope to give a contribution & help different customers like its
    aided me. Great job.

    Take a look at my web blog … email marketing

  3. I’m a bit late to the party, with regards to comments and the timing of this article, so forgive me.

    I find both the article, and a good portion of the comments more than a little unsettling – furthermore, the outright amount of tension between the IT professionals and healthcare professionals in this article shows the lack of understanding for Health IT.

    Health IT is still, currently, in it’s infancy. Like most other major changes in individuals lives – this has been a bumpy, albeit stressful transition from that of which we’ve been used to as professionals for so many years. Arguing from the IT side or the medical side is not only infectious at this point, but quite ignorant in it’s own regard.

    A software development company, individual, IT professional, etc that feels as though they can make an EHR without the working knowledge and expertise of medical professionals on their staff to guide them in creating a product that’s worthy of being used within healthcare facilities is ridiculous.

    Additionally, a healthcare professional in any form that feels as though they can make an EHR without the working knowledge and expertise of a technology professional on their staff to guide them in creating a product that’s worthy of being used within healthcare facilities is also ridiculous.

    Both IT professionals and Medical professionals come from two fields in which our skills are quite perishable, in an ever-changing industry, and taking the time it would require to become experts in both fields is quite unimaginable – though human beings do some extraordinary things from time to time.

    The animosity between IT professionals and medical professionals within the Health IT field has to stop. We are both professionals of our fields, both have the ability to earn doctorate’s in said fields, and should both be respected for the knowledge we bring to the table. The Health IT industry will continue to suffer until professionals on both sides of the house learn to work together and appreciate each other’s knowledge.

  4. I know I am not a doctor, so my use of the EHR is far different than a dr in a private practice. HOWEVER, I do concur that given the user friendliness of the EHR at my hospital, anyone who is driven mad enough times by it would have the motivation to create a better one. I actually think there is a HUGE need for doctors and nurses and pharmacists (end users/customers) to be trained in programming for EHR’s. Too often it is the “I know best” attitude, instead of collaboration that really messes up patient care and outcomes.

    For people who use EHR’s/EMR’s that are so frustrating, it is a giant step backwards, not forwards that is being taken. Because what is happening right now is that documentation supporting best patient outcomes on the EHR is more tedious yet important over actually DOING the work that would bring the best outcomes.

  5. Although I’m late to the party, I want to say that I’m dismayed and saddened to hear what Fred has to say, given that he has been such a strong, staunch supporter of open source. As a physician and also a software developer (NOSH ChartingSystem) and a staunch supporter of open source myself, the ethos of open source left the building with this post. Yeah, there are hundreds of EHR’s out there, mostly closed source, only a handful of them open source (mine is one of them), I still believe that even with the MU certification fiasco that has crippled the innovation that could really only come from open source, that open source is the only viable solution to bridge the digital divide between health care providers (those that have the $$$ and those that do not). That was why I developed my open source EHR even in the midst of the MU and deliberately being uncertified because I believe there is more out there than what physicians can have and deserve. I’m not so sure that the whole specialist analogy really fits with software developers. Not to toot my own horn, but I feel that I have been able to build an EHR based on all the countless work of other open source tools (not EHR related but all that is needed to interface a database, and create a user friendly interface that is above and beyond the old legacy systems. I hope Fred understands that open source and innovation will never decouple from each other, even if a physician also happens to be the one coding it himself. There is enough physician backlash to MU now that the void is currently being filled by viable open source alternatives.

  6. Evernote would function as a better EHR than most of the products out there.

    Why can’t I search with optical character recognition within my EHR (would help tremendously with all the scanned in labs, imaging reports, etc.)?
    Why do I have to click a million different boxes to get input?
    Why can’t I amend the templates myself to fix the errors input by some tech who doesn’t understand medical vocabulary?
    Why can’t you just leave me a bunch of free text boxes that I can dictate into with Dragon (I promise to include your almighty ICD-9 codes)?
    Why can’t you make it work easily with Dragon so I can simply dictate like we all used to instead of mousing to each individual section of the note?
    Why can’t you understand that your customer is the physician and not the insurance company and coding people?

    Every EHR out there should have a team of physicians involved in every step of development. Primary care physicians as well as specialists so that the end product is actually usable and efficient.

    Until all the systems can talk to each other and I can retrieve information from all other physicians involved in the patient’s care then it will continue to be hugely inefficient, cluttered with paper scans from other offices, and never achieve it’s purported goal.

  7. This piece is so wrong. How the hell do you know that we physician developers have no idea what we’re doing??

    Well, I know, because you have no idea what you are talking about.

  8. Yep, I agree wholeheartedly with the MDs bashing this article. And I’m an IT guy.

    Yes, most MDs who think they could do it themselves are hugely underestimating the difficulty, but many of them are smart enough to get something working, more or less, eventually. And since “something working, more or less, eventually” describes most of the commercially-available EMRs…

    Also, the assertion that no single person is capable of developing an EMR is patently false. It is true that no single person could develop an EMR to meet the typical goal of “all specialties all sizes” for commercial sale. But for a single person to develop an EMR for a specific practice is perfectly possible–because I’ve done it 😉

    I could write many pages about how attitudes like the author’s have contributed to the horrible usability of EMRs, but I’ll end by simply saying that Bernard Pegis was basically correct: “Those best suited at designing, designing and writing or even advising EMR creation are physicians. Period. All else is hubris and penny-wise/pound-foolish…”

  9. I have to agree with Alan, Rob & Nick and not the author…

    Both sides of this are woefully inadequate in understanding the needs of the other side. While EMR-X may be a great piece of software abstractly, if it fails to help a doctor *with the flow that works for him* instead of the arbitrary flow the software has (“because it’s safer for the patient” – saith the software engineer) it is useless at best and likely harmful. Those best suited at designing, designing and writing or even advising EMR creation are physicians. Period. All else is hubris and penny-wise/pound-foolish cost savings on the part of the software engineers and EMR companies who do not have adequate healthcare presence in design & advising.

    I say the above as a physician who has used 4 different EMRs but also as the author of a number of software programs which make EMRs more doctor-friendly. I started writing software 16 years before I entered medical school and have written two private EMRs so I feel somewhat confident commenting from both sides.

  10. As a software vendor in the EHR space, we wholeheartedly agree about the complexity of integration. We hear these same issues and find our customers have experienced similar frustrations. However, the difference comes in the relationship you have and the vendor’s knowledge and experience to get you through the speed bumps and curves you will undoubtedly experience when moving a practice to electronic. You will encounter unexpected issues and these are scalable, the larger the business, the more opportunities there are for issues to develop. So ask the EHR vendors about what kind of feedback their customers are giving about workflows? Then recognize that a large part of the job for you or your vendor, whether you are building your own solution or selecting a group whose business is software solutions, is to manage the expectations and prepare for the issues you’ll face when going live.

  11. Reverse doctor bashing. I love it. I understand what the writer is trying to say. There is nothing more frustrating than a bunch of amateurs flailing about with something they know nothing about in hopes of getting something better that they still know nothing about. We must ask ourselves where the need to flail comes from.

    Open-Source is a good place to start, but institutionally most of us doctors don’t get anywhere near the decision-making table where which systems to buy are made. People will always hate a one-size-fits-none system that is imposed upon them. Fred, doctors will fight you no matter what because we hate EHR. Doctors, we better stop fighting ‘cuz EHR is here to stay; let’s come up with a way to work with our tech friends. Tech friends, stop telling us we’re idiots and work with us.

  12. Having been involved with emrs since 1990, never having written or developed one, having reviewed hundreds, having owned, used and maintained 3 over the past 23 years, having used 6 different ones in hospitals over the same time frame, I have to say this is the most ridiculous piece I have ever read!
    How off target and ludicrous can you get?

  13. I would agree with the general tenant that most physicians think they could do a lot of other things quite easily. My favorite one is that they could easily have become a quant in a private equity or hedge fund by graduating with a PhD in statistics, physics, or applied math. Maybe but I bet an overwhelmingly majority couldn’t have hacked the math.

    As for building their own EMR, maybe but it would take a pretty special set of skills, expertise, and more importantly desire. Also a huge opportunity cost there in terms of what kind of time requirement it would take to even build a rudimentary system.

    EMRs might not be safe but that is asking the correctly wrong question. The question is whether there is a tangible and quantifiable improvement in safety and quality with an EMR and proposing some time of ROI. The other one is what kind of new and additional errors they create that didn’t exist already in a paper-based system.

    • tenant: a person who occupies land or property rented from a landlord.

      tenet: a principle or belief, esp. one of the main principles of a religion or philosophy.

      I’m guessing you mean the latter, not the former.

  14. Being Meaningful Use certified doesn’t mean anything if you’re not contracting with Medicare. The author should get his facts straight before insisting that someone else is wrong. Keep at it Rob

  15. This is, of course, about me and my efforts to build an EMR because of my failed attempts to find one that works with my system. In general, I agree with the idea that doctors are ill-suited to build their own EMR systems, and out of my experience over the past few months I have seen just how difficult a task it is to build one.

    What Fred misses the mark on by the longest distance is his understanding of what I am doing. I am not trying to build a fully-functional EMR that I can use and market to others. I am trying to build a prototype of a tool that I can use to make this new kind of practice work better. He doesn’t understand just how different my new kind of practice is, and how ill-suited every EMR system I tried is to this practice type. I didn’t understand it before I started trying to use them in a real-life situation. I tried five different programs and found them all so badly lacking that they threatened to destroy my business. My choice was one out of survival instinct, not hubris. It has been a very unwelcome burden to have to do this. My ultimate plan is to pass it on to an IT crew that can do their part far more skillfully than I can.

    The use of the Hippocratic oath goes a bit far as well, as it implies that I am putting my own life ahead of my patients’ needs, which is exactly the opposite, in that I’ve spent an incredible amount of time doing a project I tried to avoid, doing it because I felt the alternative was to comprimise the quality of my care.

    Finally, I think it ironic that a post aimed at “putting an uppity doctor in his place” is written with such an tone of superiority. Fred betrays the thing that many of us physicians deeply involved with the health IT (17 years of it, for me) have seen far too much: the arrogance of IT people. Fred compares himself to a surgeon that I should allow to do a procedure that I am not qualified to perform. There is a very important difference between IT folks and surgeons: the surgeon is a doctor and tech folks are not. A surgeon has had the same basic training as I have, with some additional technical training on how to perform difficult procedures. I am usually the one who decides if someone needs to see the surgeon, so I have a basic understanding of what he or she does. IT folks, on the other hand, have none of the medical training I have, and so must “learn to swim on the bus” (see my previous post to get the reference).

    For those of us who have to actually give care with EMR products, it is clear that there are major limitations to the IT industry’s understanding of health care. That’s putting it gently. In reality, many of us feel that this lack of clinical understanding breaks the very first promise of the Hippocratic oath: “First do no harm.”

    In reality, I don’t care what Fred thinks. I have consulted with a number of people in the health IT industry with far more knowledge and understanding than he has (and they have written books too!). I am just saddened at this example of the, yes, hubris of the IT industry toward the rest of the world, and am frustrated at being accused at risking harm to my patients by one of those who holds the gun.

  16. As LegacyFlyer said, the current crop of EMR systems (open or not) may be MU certified, but it does not mean that their use guarantees safety or productivity.

    I also think the comparison to heart surgery is misleading. Having a computer science degree or experience in EMR development may make things run faster or be completed sooner, but it doesn’t mean that because someone went to medical school that they can’t learn to program.

    As you provided, there are bodies of knowledge from which to study and learn to develop a safer EMR system.

    There are also books and schools to teach someone who is not a heart surgeon to become one.

  17. It is funny that this piece is posted at the same time “Consumers’Perceptions of Patient-Accessible Electronic Medical Records” is published. The link is below. This study looks at the valuable benefits of EMR for patients especially those who are most vulnerable consumers. And speaks directly to the need for these EMR and patient portals to be done by professionals who understand both consumers, learning, and communications.


    • “This study looks at the valuable benefits of EMR for patients”

      Nope, not even close.

      As the title of the article indicates, the study looks at the perceptions of the patients (all 28 of them). Whether that eventually translates into benefits is completely unknown.

      • As the lead author of the study mentioned, I agree – these were the perceptions of consumers who were introduced to the concept and workings of patient portals AND who did not yet have access to a system.
        Our next article ( under review) is the actual usability of 3 exemplars of portals by 54 underserved, low literacy consumers. There are many “fixable” barriers to use for consumers.


  18. Fred: Care right now can often be considered shoddy, whether or not the clinician is using an EHR, or is using a professionally-built one versus one he/she has created.

    Without defining a few metrics for “good care”, how can we determine whether a clinician will better serve his or her patients using a home built EHR versus a “real” EHR?

    I agree, however, that building a functional EHR is very complicated, surely much more so than most clinicians realize.

  19. Dude,

    I am one of your many admirers. I was especially impressed by your detective work in the disappearance of Bunny.

    I think you are being too nice to Fred. Intellectually speaking, he has peed on your rug Dude. You need to draw a line in the sand and let him know that this aggression will not stand.

    In lieu of getting you a toe with green nail polish by 3 o’clock, I would like to ask you the following question:

    “If the useability of EMRs was not so abysmal, why would any doc want to write his own?”

    I would also like to comment on his statement:

    “Make no mistake, you can kill someone with a shoddy EHR”

    Thank god the current crop of EMRs has been so carefully checked for safety and useability – NOT

  20. The field is wide open. All of the EHR devices out there serve as disruptors to safe and efficacious care.

    The devices are too complex to individualize care. They are great for simple illness, like hangnails and strep throats.

  21. Dude – I am conflicted about this piece, although my sense is that your heart is in the right place. Your advice seems contrary to the spirit of innovation and entrepreneurship that made the tech industry what it is. It could also be seen as just a little self-serving, given that you are in this line of work ..

Leave a Reply

Your email address will not be published. Required fields are marked *