Ironically, it's also a somewhat of a circular problem, given the inherent complexity of medical processes, every organization has organically formed their processes over decades. When choosing software solutions, they pick software that caters to their specific needs, rather than change processes to fit existing software. This results in vendors building endlessly configurable products that add even more complexity. As a potential new entrant, this means you'd need to not only support N processes, but something like (number of clients) * N processes.
There are some initiatives towards EHR interop (e.g. FHIR), but from what I've seen so far, they suffer from similar problems. As in the standard is made so flexible to cover all situations that you can make things that are 100% compliant, but completely incompatible.
Yeah, I've seen the term "sociotechnical" used to describe this relationship between software and process. A process is built in part for a system, and therefore the system in part needs to support the process. Changing the setup isn't just a technical challenge, it's a challenge in creating sociotechnical change. I think it's a very easy thing to underestimate.
Ironically, it's also a somewhat of a circular problem, given the inherent complexity of medical processes, every organization has organically formed their processes over decades. When choosing software solutions, they pick software that caters to their specific needs, rather than change processes to fit existing software. This results in vendors building endlessly configurable products that add even more complexity. As a potential new entrant, this means you'd need to not only support N processes, but something like (number of clients) * N processes.
There are some initiatives towards EHR interop (e.g. FHIR), but from what I've seen so far, they suffer from similar problems. As in the standard is made so flexible to cover all situations that you can make things that are 100% compliant, but completely incompatible.