Should EHR Vendors Employ Clinician “Bug” Finders?

Reading through Anne Zieger’s article today about EHR usability and the tie to common safety threats highlighted to me how poorly many EHR vendors do at ensuring their EHR software won’t lead to patient safety issues. As I thought about it more, it reminded me of the work software companies do to ensure there are no software bugs as they roll out new releases of their software. Should we do something similar with patient safety threats?

For those not familiar with the software bug finding process, it can get really intense. No doubt some companies do this better than others, but every EHR software vendor has some sort of software bug finding process. If they don’t, well that’s a whole other issue altogether.

When I was in college I worked at a software company. Along with coding their website, they asked me to take part in their software testing process as well. The goal was to ensure that new releases of the software didn’t introduce new bugs that would cause errors or bad experiences for their users. This was a sometimes fun and sometimes tedious task. Tedious when you couldn’t find any issues and fun when you found something that didn’t work quite right.

I’m sure that software companies have come a long way in their testing scripts, but at the time we used a mix of testing very specific use cases and workflows along with some freestyle testing where we did abnormal workflows to try and get the software to break. Then, we’d report any errors, flaws, bugs, etc we found during our testing. Sometimes these would be new issues introduced by the new code and other times it was flaws that had been in the system for a long time. I won’t go into software programming bug theory here, but the simple description is that all software has flaws. It’s just how many and how impactful are they.

No doubt all healthcare IT software has some sort of software quality testing process. Large EHR vendors likely have full teams of people whose job is to test the latest releases for flaws. As I thought about this, I wondered if any healthcare IT software companies had doctors and nurses on staff whose job was to test for patient safety issues. I haven’t heard or seen anyone do this, but maybe they should.

The idea is simple. Have a doctor, nurse, front desk staff, etc test the latest releases of your software and evaluate patient safety issues with the software. Some of this could be due to a bug in the software and some of it could be due to other factors. However, identifying these issues could inform the programmers on how to better prevent these safety issues from happening.

No doubt, this is opening a bit of a Pandora’s Box. Similar to how all software has bugs, all medical software has potential safety issues as well. The key is to identify those issues, evaluate the impact and likelihood of these issues, and then work on ways to mitigate the risk. I’ll be interested to see how many health systems take on this testing as part of their upgrade cycles as well. No doubt some progressive organizations won’t rely on their EHR vendor to do all the testing.

As I think about the medical malpractice risk associated with EHR software that’s coming down the pipe, I can see an EHRs ability to avoid patient safety issues becoming a powerful feature. Plus, it’s just the right thing to do for the patient.

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.