I think Microsoft HealthVault was more of what you describe, where it's a portal intended to be used by patients.
So the hospital is willing to shell out a ton of cash so that they have a Very Secure system that helps them better manage their cash flow. If you walk in as a doc with (for example) a nifty phone app that lets you track your patients in real time, you'll confront 2 problems: 1.) the hospital won't let you connect because it'll assume (possibly incorrectly) that it's a huge security hole. 2.) even if they did let you connect, their EMR is non-standard (basically all of them end up non-standard) and there's no lingua franca protocol for medical data, so your app is incompatible.
It's really really tricky to solve all those issues AND have it be cheap enough for a doc to be willing to shell out for it out of pocket. I personally you'd need that kind of consumer-side scale to get enough competition to get medical software to innovate more quickly. I will say a common interchange format would help a lot, that's one of the objectives FHIR had, and the industry has been slowly adopting it.
You accurately point out revenue personnel and practice managers as key players here, and yes they're the ones that usually push EMRs etc. But the front line workers are kind of disconnected from the design and functionality of the EMR.
Put another way you have software that's bought by one person (hospital/provider), it's used to collect data by a totally different person with different needs (docs/nurses), and it's paid for eventually by another person who has no idea how it works nor any direct pressing need for it (patient/but let's be real, insurance company/government).
Without a tight connection between who pays for the software, who uses the software and who benefits from the software (most consumer software is a pretty tight loop), it's hard to have a good virtuous cycle of innovation coming from customer/user insight/observation/needs.
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.