EHR Programmer Shadows Physician

I was recently browsing through blogs and came across this post on the Elation EMR blog about their practice of having developers shadow a physician as part of their hiring process. What an amazing idea! I loved this paragraph which says a lot about the health IT industry:

I was terrified. I’d worked in healthcare IT for years, but even when I worked at startups I’d been three or four steps removed from the patients and even the clinician users. Being at the point of care, watching someone’s grandfather discuss his current prescriptions with his longtime primary care provider was revolutionarily human to me—and incredibly intimidating. Add to that the pressure that I didn’t have the job yet; this was one of the final stages of my job interview.

I think if we did a survey of healthcare IT programmers, we’d be saddened to know how many of them have never been part of a clinical interaction. I bet a huge percentage of these programmers’ only point of reference for healthcare was when they went to the doctor themselves.

At TedMed I ran into a former Epic programmer who confirmed what I describe above. They were there to program something to spec. They weren’t there to understand the clinical context of what they were creating. There is something very different between a programmer involved in the design process and one just designing to spec.

Obviously, Elation EMR takes the opposite focus on their approach to EHR development. The above policy adds some depth to Elation EMR Founder Kyna Fong’s post asking “Is You EHR Clinically Valuable?“. I love when a company doesn’t just talk about something, but their actions reflect their values.

I bet many EHR vendors would be embarrassed to ask their staff if they have ever shadowed a physician. No doubt, the number would be very low.

About the author

John Lynn

John Lynn

John Lynn is the Founder of, a network of leading Healthcare IT resources. The flagship blog, Healthcare IT Today, contains over 13,000 articles with over half of the articles written by John. These EMR and Healthcare IT related articles have been viewed over 20 million times.

John manages Healthcare IT Central, the leading career Health IT job board. He also organizes the first of its kind conference and community focused on healthcare marketing, Healthcare and IT Marketing Conference, and a healthcare IT conference,, focused on practical healthcare IT innovation. John is an advisor to multiple healthcare IT companies. John is highly involved in social media, and in addition to his blogs can be found on Twitter: @techguy.


  • I wonder what kind of house a buyer would end up with if an architect were to prepare drawings and hand these over to a builder without consulting with the buyer?

    I don’t however agree with “There is something very different between a programmer involved in the design process and one just designing to spec” – this is why we have developers.. They consult with everyone who will be an end user, plus supervisors, managers and they write up tight specifications that leave no stone unturned. If the programmers have questions, they go to the developers.

    Many software manufacturers today outsource programming. The programmers often work in other cities, countries, even continents, so involving the programmer in the design process is not feasible, even it were to have some benefit.

    Which brings us to the basic question of “why ‘develop’ an EHR?” when you can get an off-the-shelf product that can be configurable as opposed to having to be customized or developed?

    The only difference between development/customization and configuration is that it takes less time and costs less money. A lot les time and a lot less money. How about a factor of 10 or perhaps even 100? Ask Maine Medical what their experience has been.

    It is no less important when configuring an EHR to consult with all of those who are going to end up being end-users of the software. If the configured product does not let end-users work the way they like/need to work, then they won’t use it and the system will fail in it’s implementation.

    The correct skill needed when configuring off-the-shelf EHR software is a “facilitator” See “The Facilitator is Coming” at

  • I have no doubt that beyond the hiring process, Elation EHR designers and programmers consult with more than one current and potential user. That being said, I would worry that shadowing one single physician is more dangerous than shadowing no physicians because it gives the shadower a very narrow lens through which to understand a physicians workflow. I can only imagine the design meetings between programmers who each shadowed a different physician arguing over which is the optimal workflow design, each programmer arguing from their own experience, none of whom are wrong, and none of whom are right.

    Each and every physician’s workflow even within a single specialty has the tendency to deviate from one another and once you get out of one specialty and into another the deviations expand and vary much more wildly. No matter who you’re designing for, even if it’s just one specialty you must consult a multitude of potential users.

  • Andrew,
    I agree that you need more than one physician perspective. Plus, I think a design meeting where each programmer is arguing from a different physician’s perspective is a really healthy thing. By having multiple perspectives it will take longer to decide on a proper design, but it will also force them to reconcile the differences between the various physician workflows.

  • Nothing wrong either in an Adaptive Case Management (ACM) environment with each physician having his/her own workflow (aside from the obvious disadvantage of taking longer when revisions are needed).

    The reason this is feasible is in ACM you tend to have process fragments, not processes, that people/robots/software thread together at run time.

    So, in theory, each instance is unique.

    BUT, one of the main advantages of ACM over BPM is that with the former you can accommodate any mix of unstructured work versus structured work because ACM rule sets operate behind the scenes to provide the needed governance to allow variations of workflow at a low level. Any major excursions away from “best practices” will be “reined in” by the rule sets.

Click here to post a comment