One of the huge challenges that an EMR software vendor has is the long lists of enhancement requests that they receive from end users. Managing these requests has got to be one of the most challenging jobs of any EMR vendor’s development and support teams.
An EMR vendor has so many often conflicting motivations related to which enhancement requests they add to their product. I won’t go into all the details of their job here, but let’s just say they’re walking a very small tight rope. On one side, they want to be able to create enhancements that will sale more product. On another they want to keep their current users satisfied. On the other, they don’t want to make their product to specific to one area, region, specialty (unless it’s specialty specific), insurance plan, provider type, etc etc etc. Another side wants to be able to keep innovating the product in ways that weren’t suggested by the end users. Then of course each EMR vendor wants to keep some of their enhancement plans private as part of their “competitive advantage.”
Honestly, none of this is new to software or EMR. We’ve been dealing with this for a long time. However, I don’t know of any EMR company that really manages this process well. That said, I’d love to hear about other EMR vendors approaches to collecting, managing and implementing software enhancement requests.
Here are just a few of the components that I think a good EMR software enhancement request system should have:
- Simple, but complete method for requesting ehancements
- Translation of the enhancement request into actionable enhancement (this is also important for helping to filter out repeats and other such noise)
- Feedback to the end user of what was done with their request
- System for users of the EMR to see all the enhancement requests
- Method for users to be able to support enhancement requests that are already made (this helps an EMR vendor prioritize the requests)
- Method for users to provide comments on already created enhancement requests (ie. refine and improve the existing requests)
- Internal enhancement plans are part of the system
- Completed enhancement requests are noted for those interested in following the progress
As I was listing these things I think that my view of enhancement request is partially clouded by open source projects (maybe there’s an open source EMR that does the above well?). However, I think that a number of open source projects do a really good job of managing enhancement requests. The non open source software world can learn a lot from open source software in this area.
I think one of the key things I’d love to see an EMR vendor do well is involving the “crowds” of EMR users (coined “crowdsourcing”) in the prioritizing and planning of future enhancements. Users of an EMR have a wealth of knowledge related to the product and I’ve yet to see an EMR vendor tap that knowledge really well.
I think doing the above would solve a common phrase I’ve heard after doing an EMR software update: “Why did they add that feature?” followed by the question “Why don’t they add this?”