I'm going to take some guesses here but I'd love to hear a discussion about this from people with experience in medical software.
Medical software seems like it is rife with mandated requirements, likely written by people with no regard to real-world usage implications. By this I mean decisions that are akin to attempting to increase security by password complexity and expiry requirements -- when the reality is that decreases security by making users write down and/or cycle through easily-predictable passwords.
I would also guess the purchase cycle is very disconnected from its users. The people actually making the buying decisions never actually touch the software. This is probably also like a lot of enterprise software: very expensive, long contract/license lengths, high switching costs.
A relatively minor point but there's also no dogfooding: The developers building the software are not medical professionals and thus never use it themselves. They don't get to see the daily pain.
The result of all this would be very little incentive to build anything beyond "working" software -- spending time on UX or UI design just eats into profits. The type of developers/PMs/etc that excel at and advocate for this type of work are likely not going to stick around (or even work there in the first place), making improvements even less likely.
Have spent decade more or less as health tech security and privacy consultant, checking in.
Requirements come from the institutions that fund the solutions ("solutions," not products) and not the users themselves, so engagement with end users is limited. It's very waterfall, no product managers, just "business analysts," whose only leverage is their perceived relationship with "the client," who may or may not be represented by an actual user.
I've thought a lot about how to disrupt healthcare, and the only viable way I can think of doing it is selling new products into emerging markets that don't yet have ensconced bureaucracies running health. The most successful grassroots medical product I am aware of is "Figure 1," but any product going into western world healthcare is going to be %95 enterprise solution and %5 health related.
An "Uber for stitches" product would be illegal in most countries, but that's the only kind of innovation I can see driving change for most people.
Medical software seems like it is rife with mandated requirements, likely written by people with no regard to real-world usage implications. By this I mean decisions that are akin to attempting to increase security by password complexity and expiry requirements -- when the reality is that decreases security by making users write down and/or cycle through easily-predictable passwords.
I would also guess the purchase cycle is very disconnected from its users. The people actually making the buying decisions never actually touch the software. This is probably also like a lot of enterprise software: very expensive, long contract/license lengths, high switching costs.
A relatively minor point but there's also no dogfooding: The developers building the software are not medical professionals and thus never use it themselves. They don't get to see the daily pain.
The result of all this would be very little incentive to build anything beyond "working" software -- spending time on UX or UI design just eats into profits. The type of developers/PMs/etc that excel at and advocate for this type of work are likely not going to stick around (or even work there in the first place), making improvements even less likely.