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.
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
http://wp.me/pzzpB-aG
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.
[…] that vendors are “getting it.” For example, I really liked a story John wrote about how EMR vendor Elation requires programmers to shadow a physician as part of the hiring process. To my mind, this kind of thinking is far more likely to bear fruit […]
[…] a recent post on EMR and EHR, John Lynn points out an up-and-coming EMR (Elation EMR) company is out there […]
[…] blog item by John in which he describes how prospective programmer hires at Elation are required to shadow a physician as part of their hiring process. In both cases, the people who will be working with the software […]