>But the front line workers are kind of disconnected from the design and functionality of the EMR. We have front line personnel complaining to us all the time

>But the front line workers are kind of disconnected from the design and functionality of the EMR. We have front line personnel complaining to us all the time that the EMR is slow and unwieldy and suggest features to bypass the features that the EMR has built. These are applications that block the UI thread for nearly every database or long-running call, a veritable sin these days. Most apps would come from people who have worked directly with the EMRs before, so it's rare to have one thing that talks to all of them but not impossible. If there is a perfect example of institutional knowledge, EMRs would be it. As a developer, you'd be focusing your marketing on people who already have that solution and position it as an addon. Independent products are difficult to do because interop barely exists and that interop standards that do (like HL7) have very little constraints or an escape hatch to add whatever you like. The reason you have to take this parasitic marketing stance is due to the massive effect that EMRs have on every day workflow. Many decisions for buying software are made in light of how it works with the EMR if it's relevant to patient care. EMR choice is akin to operating system choice for the hospital or practice. And there could well be a tight connection between the front line workers and the EMR developers, but it wouldn't matter because long-term contracts prevent any threat of either side losing their jobs soon.