In Shirie Leng’s excellent post, “The Email I Want to Send To Our Tech Guys But Keep Deleting, Dr. Leng lists a series of problem areas which plague software development in healthcare. Making things better requires taking a closer look at the specs we use. The new-age consumer-focused software companies can build products with outstanding usability because they start and end with the specs.

I have spent time at several academic medical institutions, and their software solutions are very much the same. At one, I was given this five-page table of portals and documentation systems with instructions on how to log in.

The punchline: I’m asked to have a different username and password for each of them.

I give much credit to the physicians who navigate these software applications, including the one that compiled the list I showed above. But physicians have allowed poor design of their technological solutions for too long, and have neglected to demand interoperability from software vendors.

The number of required training hours is a good indicator of usability. (And many of the items on the list come with long training hours.) While physicians have accepted these courses as part of their jobs for years, why should formal training be necessary to operate an EMR? Most of the tasks of ordering and documentation are no more complicated than paying your credit card bill or shopping online.

I’ll only scratch the surface of this usability problem by highlighting several notably poor implementations. I won’t even get into the inefficiencies in ordering and documentation.

My first example is an EMR system that is used to order medications and communicate data with nurses [below]. At a glance, there are no fewer than seven distinct menus on the screen at the same time. In my experience using this EMR, I’ve clicked ten percent of these buttons (and I would estimate that 90% of the work occurs in 5% of the buttons). The poor organization of information leads to lengthy searches for the right information, and often, the unawareness of critical information that is hiding under a nondescript label.

Lesson: Menus should have clear hierarchy.

My second example is a shift-scheduling application [below]. Here is an example of of how applications can invent interfaces rather than using the ones familiar to us. The primary menu is on the left-hand side. Upon clicking on one of these options, the secondary menu is displayed right below the header. The tertiary menu, however, goes back to the left-hand side. The issue here is a lack of consistency and predictability.

Lesson: The user’s next step should be salient contain a reasonable number of options (between two and five).

In today’s hospitals, with so many concurrent information systems, some have devoted resources to “hacking” the systems to mine data and present it in one, coherent, application. Initially, I applauded these efforts, for building a tool around user needs, despite the difficulties of lack of interoperability and APIs in the systems they have paid millions for.

These homegrown solutions, however, can fail without good guidance from clinicians. The third example involves one such homegrown aggregator of content. After selecting a patient using the application, the user arrives at a menu that organizes data by department [below].

Where would I find a full-body CT, or echocardiogram, or rheumatology consult? I can think of a handful of categorizations that make more sense, including organ system or type of encounter. The issue here is that there is no way to gain a comprehensive understanding of a patient without clicking on thirteen categories and reading all the information, when in reality, a physician-to-physician handoff requires that information to be conveyed in less than five minutes.

Lesson: Organization of information needs to be built to facilitate the fastest understanding of the patient possible, not by departmental boundaries or other historical or political distinctions.

Luckily, the click of an “info” button clarifies everything [below], as my patient waits for me in the next room.

I have only touched on some of the organizational problems of these systems. There are separate portals for medical education videos, procedure logging, evaluation, and incident reporting that have their own issues. These are some of the technological barriers that make work in the hospital far from frictionless.

Information technology within the confines of medicine remains in the dark ages. Hospital information officers boasting 20 years of experience are, in effect, dinosaurs. That’s because the past ten years has seen tremendous innovations in usability, design, and security. Medicine needs the agile developers, the designers, and user testers.

Before the software revolution can hit medicine, we providers need to speak the language of the software developers in order to be good consumers of technology.

Physicians, repeat after me: Menus should have a clear hierarchy, the interface should be predictable, data should be organized how I think about the patient, and I do not need a training certificate to use a software program.

David Do, MD is a graduate of The Johns Hopkins University School of Medicine and a resident physician at the Hospital of the University of Pennsylvania. He is an agile software developer and Chief Technology Officer at

11 Responses for “How Programmers Think: A Doctor’s Guide to Building a Better EMR”

  1. Whatsen Williams says:

    Best devices (there are not any) have redundancy, paucity of gibberish, and do not tolerate absurdity, and, allow individualization of care.

  2. Adam Hayes says:

    This day in age software training certificates are a ridiculous requirement, and would not be widely tolerated by most business communities. End users at all levels need to ask for a seat at the table and be involved during EMR software development, scoping, and testing, instead of allowing programmers to solely dictate the hierarchy and function.

    • David Do, MD says:


      You’re absolutely right. We tolerate long training to use bad interfaces in medicine. Interface changes can involve multiple committees and can take months to deploy. We could learn a lot from rapid prototyping and agile development.

  3. Boris Katz says:

    Sorry, but let me respectfully disagree. The indication of “good” EMR is measured by the time a TRAINED user (physician) spend to accomplish his every patient encounter task – less time – better.
    The “easy to master” approach with multiple prompts, “Ok”, help bubbles, etc. works well while you master the software, but later becomes a time wasting burden. Of course, I do not mean that the user interface should be confusing, but as I emphasized above: the main criteria to judge is how much time a trained user needs to accomplish the task with the computer.

    • David Do, MD says:

      Boris, Thanks for your reply. I think over the past ten years we’ve been shown that you don’t have to choose between simplicity and power in software. For example, apple products pay attention to design and simplicity and yet they are still the choice for most software developers. I will also add that I am a trained EMR user who is constantly surprised by how difficult it is to complete simple, common tasks.

      • Boris Katz says:

        If you are interested to see – I will be happy to show you my software in action. Do not take it as a sales pitch – most likely my software is incompatible with your EMR. I just want to show you what in reality can be done. My e-mail is

  4. Boris Katz says:

    Let me add some more to the discussion. When you hire a new nurse/MA just out of school they know some basics, but you have to invest some time to teach them what and how to perform in your practice. As time goes by the nurse/MA performs much better because they learn two things: rules you set and your pattern. The very same approach should be available with the software – to be able to set rules and the software to perform depending on your pattern (statistics). Once the above is achieved – your performance soars up. In software terms the above is called software intelligence, but the existing EMR systems do not have it. Being a developer of medical software intelligence I know the subject “first hand”: the physician satisfaction becomes 100%, the productivity growth by about 30% and the stress (do not know how to measure) goes down.

  5. Thanks a lot for sharing this with everyone you really recognise what you are speaking approximately! I’m impressed, I need to acknowledge. Rarely do I encounter a website that’s similarly educative and interesting, and without a doubt, you’ve hit the nail to the head. youtube views

  6. beats by dre says:

    Venture leasing is also very flexible. By structuring a fair market value purchase or renewal option at the end of the lease, the startup can slash monthly payments. Lower payments result in higher earnings and cash flow. Since a fair market value option is not an obligation, the lessee has a high degree of flexibility and control. The resulting reduction in payments and shift of lease expense beyond the expiry of the transaction can deliver a higher enterprise value to the savvy entrepreneur during the initial term of the lease. The higher enterprise value results from the startup’s ability to achieve higher earnings, upon which most valuations are based. beats by dre

Leave a Reply


Founder & Publisher

Executive Editor

Editor, Business of Healthcare

Contributing Editor

Contributing Editor

Business Development

Editor-At-Large, Wellness

Editor-At-Large, Europe



The Health Care Blog (THCB) is based in San Francisco. We were founded in 2003 by Matthew Holt. John Irvine joined a year later and now runs the site.


Interview Requests + Bookings. We like to talk. E-mail us.

Yes. We're looking for bloggers. Send us your posts.

Breaking health care story? Drop us an e-mail.


We frequently accept crossposts from smaller blogs and major U.S. and International publications. You'll need syndication rights. Email a link to your submission.


Op-eds. Crossposts. Columns. Great ideas for improving the health care system. Pitches for healthcare-focused startups and business.Write ups of original research. Reviews of new healthcare products and startups. Data-driven analysis of health care trends. Policy proposals. E-mail us a copy of your piece in the body of your email or as a Google Doc. No phone calls please!


Healthcare focused e-books and videos for distribution via THCB and other channels like Amazon and Smashwords. Want to get involved? Send us a note telling us what you have in mind. Proposals should be no more than one page in length.

If you've healthcare professional or consumer and have had a recent experience with the U.S. health care system, either for good or bad, that you want the world to know about, tell us about it. Have a good health care story you think we should know about? Send story ideas and tips to

REPRINTS Questions on reprints, permissions and syndication to



Affordable Care Act
Business of Health Care
National health policy
Life on the front lines
Practice management
Hospital managment
Health plans
Specialty practice
Emergency Medicine
Quality, Costs
Medical education
Med School
Public Health

Electronic medical records
Accountable care organizations
Meaningful use
Online Communities
Open Source
Social media
Tips and Tricks


Health 2.0
Log in - Powered by WordPress.